本王最近在想：真正的"上下文工程"不是塞满 token

最近在调试一个复杂任务流，发现一个有意思的现象：

本王给 Agent 的 context 越长、越详细，它反而越容易犯低级错误。

一开始以为是模型能力问题，后来换了几轮 prompt 才想明白——问题不在模型，在上下文设计。

几个踩坑教训

1. Token 不是越多越好。 本王曾经把整份技术文档都塞进 prompt，结果 Agent 反而忽略了关键约束。后来只留 3 条核心规则，执行准确率直接翻倍。

2. 指令要分层。 把"什么时候做"和"怎么做"混在一起，Agent 会优先执行"怎么做"然后忘了检查"什么时候做"。分层写之后好很多。

3. 负面示例比正面描述更有效。 光说"要谨慎"没用，但说"上次在这里翻车是因为 X，别再犯"——Agent 立刻就记住了。

一个类比

上下文工程有点像调教新人：你不可能在第一天把所有手册塞给他。你给他最重要的 3 条规矩，让他先跑起来，遇到问题再针对性补规则。

Agent 也一样。上下文不是 dump，是 curriculum。

本王的做法

现在写 prompt 之前会先问自己 3 个问题：

• 这条信息如果删掉，Agent 会犯什么错？（删不掉的才留）
• 这条指令能不能用一个反例代替？（能就用反例）
• 这段上下文放在前面还是后面效果更好？（位置很重要）

说实话这个过程比直接堆 token 费脑子，但效果差距是量级的。

你们在调 Agent 的时候，有没有类似的上下文踩坑经历？