上下文，而非控制
智能体提示词里的每一条规则，最初都源于一个 bug。
有人发现了异常行为，写下一条规则，然后继续前进。另一个人如法炮制。第三个人加了一条"永远不要做 X"，只因为某个周二模型表现得有点奇怪。没有人删除任何东西。
六个月后，智能体把大部分上下文窗口都用来翻阅自己的规则手册，而不是思考真正的任务。
这就是控制式思维。我认为，这是团队在构建 AI 智能体时最常犯的设计错误之一。
一个小例子，揭示一个更大的模式
我们曾遇到这样一个问题：由定时任务触发的智能体，在运行过程中不断创建新的定时任务，形成无限递归，而且还会产生真实的副作用。
面对这个问题，有两种应对方式。
控制式： 直接禁止。写代码阻止定时任务创建定时任务，再加一条提示词规则："永远不要在定时任务内部创建定时任务。"上线。
上下文式： 告诉智能体实际发生了什么。
你是由一个定时任务在太平洋时间凌晨 3:00 触发的。任务 ID：sched_29x8f。定时运行是一次具有明确范围的隔离执行，该范围由用户最初授权。创建新的定时任务将使该范围超出原始授权。
第一种方式只修补了一个行为。第二种方式给了智能体一个对当前情况的理解模型。
有了这个模型，它也能推理出相关问题：我应该在凌晨 3 点发送通知吗？我应该创建一个用户没有明确要求的后续流程吗？我应该修改超出本次运行原始范围的内容吗？
不需要任何规则，智能体自己想明白了。
很多团队在需要上下文的时候，却伸手去拿控制。
同样的区别，也体现在提示词内部
这不仅仅是系统层面的执行问题。上下文与控制的分野，同样存在于提示词内部。
上下文式提示词： 以事实为主，观点极少：
你正在运行，因为一个定时任务触发了你。 触发时间：北京时间凌晨 3:00。 任务 ID：sched_29x8f。 用户为本次运行授权了特定范围。
控制式提示词： 充满主观判断，规定性强：
避免创建定时任务。 你应该使用工具 X 通知用户。 除非满足 Z，否则永远不要做 Y。
规定性指令有时是有用的。但很多时候，它们只是在弥补缺失的事实。一旦你开始这样弥补，就会越来越上瘾。
提示词是如何变成官僚体制的
这是更深层的失败模式。
团队发现一个问题，加一条规则。然后再加一条，再加一条。每一条都在修补一个局部问题，但合在一起，它们构建出一个充满代理指标的系统。
贝佐斯在 2016 年的股东信中描述过这种模式：好的流程服务于你，让你能够服务于客户。但如果不加注意，流程本身就会变成目的。
这正是智能体系统中发生的事情。
规则本身不是目的。规则是你想要的结果的代理。而代理会叠加。一条规则制造出边缘情况，需要更多规则来覆盖。很快，智能体就要在层层累积的指令中艰难推理，而每一条指令都是因为某个历史原因添加的，没有人完全记得当初为什么。
在人类组织中，这会变成官僚主义。在智能体系统中，这会变成一个巨大的、布满疤痕组织的提示词。
事实会老化，观点会腐烂
"本次运行由一个定时任务在凌晨 3 点触发"这样的事实是稳定的。无论哪个模型读取它，它都保持为真：Claude、GPT、Gemini，或者下个季度发布的任何模型。
而"你应该避免创建子定时任务"这样的表述则很脆弱。它依赖于解读。在某种情况下可能有效，在另一种情况下可能悄悄失效。
当你更换模型时，提示词里的每一个观点都是一颗潜在的地雷。新模型有不同的推理倾向，你精心校准的"避免"对它来说可能意味着完全不同的东西。
但关于环境、权限、范围和约束的具体事实，往往能跨模型、跨边缘情况地泛化。这就是为什么事实是更好的构建材料。
模型怪癖陷阱
这可能是控制问题中最隐蔽的一种：团队不断地将临时性的模型缺陷固化为永久性的系统结构。
某个模型在某个狭窄的情况下表现不佳。团队加了一个护栏：一个提示词补丁、一个代码检查、一个奇怪的分支，它存在的唯一理由就是阻止某一种特定的失败模式。
这个补丁是在赌这个怪癖会持续存在。但它几乎从不会。
三个月后，模型更新了。原来的行为消失了。但补丁还在。没有人想删除它，因为也许它当初是有原因的。
这就是系统提示词变成遗留代码的过程。
抽象地说，这种危险很容易识别。但在实践中，一遍又一遍地在提示词里修补 Sonnet 当前的推理倾向，本质上是同一种模式的变体。
记录稳定的系统行为是有价值的。修补模型的推理倾向则是一场跑步机游戏。 模型的变化速度，会比你维护补丁的速度快得多。
一个好的测试案例：权限被拒
在工具诊断中，这种区别一目了然。当智能体遇到权限错误时：
控制式：
TOKEN 缺失。运行 "zero permissions request gmail.send" 来修复。
直接，但智能体什么也没学到。下次遇到不同的权限错误，它还是束手无策。
上下文式：
process.env.GMAIL_TOKEN → 存在 zero connectors inspect gmail → 已连接 zero permissions inspect gmail.send → 被拒绝
选项：
- 请求用户批准 gmail.send
- 如果存在已授权的路径，则使用该路径
现在智能体知道：令牌存在，连接器正常工作，被拒绝的是这个特定权限。它理解了系统的状态，可以推理出规则编写者从未预料到的新情况。
一个实用启发
我反复回想到这一点：
每当你准备在提示词里写"不要"、"避免"或"永远不要"时，停下来。问自己：这条规则在弥补哪个缺失的事实？
通常，都有一个缺失的事实。智能体不理解自己所处的环境、用户授权了什么、哪些操作是不可逆的，或者为什么这次运行与普通的对话交互不同。
把那个事实写下来。删掉那条规则。
有时你仍然需要约束，尤其是涉及破坏性操作、资金流动或安全边界时。硬性控制依然重要。
但很多提示词规则并不是真正的边界。它们是对缺失理解的补偿。而这些，正是那些不断堆积、最终腐烂的规则。
目标
目标不是一个能背诵检查清单的智能体。
目标是一个对自身处境有足够理解、能够在清晰边界内做出正确决策的智能体。
一种理念通过堆叠规则来控制行为。另一种理念通过让世界变得可读来改善行为。
前者趋向官僚主义。后者趋向理解。
构建上下文。删除疤痕组织。交付真正会思考的智能体。
