行动结构比 Agent 的忙碌更重要

一个会不停调用工具的 agent，和一辆油门踩死但方向盘松了的车，是同一种事故。

你看到的不是「努力」，是系统在缺少结构时，用动作量冒充进展。

你以为是能力问题，其实是控制结构问题

控制论里有一句土话：没有反馈回路的「努力」，只是开环噪声。

多步骤 LLM 系统特别像开环放大器：token 越滚越多，日志越长越像在工作，但误差信号可能从头到尾没被采样过。

所以真正决定结果的，从来不是「调用了几次检索」或「跑了多少轮 ReAct」，而是四类东西有没有被设计成可检验对象：

1. 目标：有没有从意图压成可执行、可判定的状态描述（而不只是口号）。
2. 步骤：每一步是否理论上能缩小「当前状态 → 目标状态」的不确定性。
3. 反馈：系统是否能在有限成本内拿到「偏了没、偏在哪」的信号。
4. 停机：什么条件下必须停、复盘、升级策略——而不是「再试一轮也许就好了」。

缺任何一类，你都会得到同一种产物：busywork——看起来专业、听起来合理、但对目标分布的贝叶斯更新接近于零。

为什么多智能体更容易集体空转

多 agent 把问题从「一个脑子乱想」升级成「多个脑子互相确认乱想」。

空转在协作里会被误读为「分工很细」：

• 输出变多 ≠ 信息变多。
• 子任务变碎 ≠ 风险被覆盖。
• 互相 @ 很勤 ≠ 接口契约更清晰。

用信息增益问一句就够狠：上一步产出的新信息，有没有改变下一步的决策空间？ 若答案经常是「没有」，你不是在做系统，是在做舞台剧道具。

四类结构，各怎么验收

目标：写成「世界在某 observable 上应满足什么」而不是「帮我做好」。

坏目标触发词：更智能、更自然、用户体验更好——全是不可裁判的形容词堆。

步骤：每一步要能说清假设和若假设错会怎样。

若某步失败只会导向「再生成一段差不多的」，那这一步没有结构，只有修辞。

反馈：区分三类信号——结果信号（做对了没）、过程信号（哪一步引入了误差）、元信号（评测本身是否漂移）。

没有过程信号，你会永远在结果层打地鼠。

停机：写清三类停机——成功停机、资源停机（时间/钱/token）、认知停机（连续 K 步信息增益低于 ε 必须交还人类）。

没有第三类，系统会把「重复」误认为「坚持」。

最小检查法（每次跑工作流前 60 秒）

对每个即将执行的步骤，只问三句话：

1. 这一步预期生成什么新信息？（事实、约束、反例、可执行计划差分，都算。）
2. 它如何具体改变下一步的搜索方向或工具选择？（说不出来＝别做。）
3. 若什么都没变，成本由谁承担？（默认你承担，就该砍掉这一步。）

把这三问写进 runbook，比换十个 prompt 模板有用。

跨域锚：停机问题与「假装有进展」

图灵意义上的停机不可通解，但工程上的停机必须可解。

很多 agent 流水线的问题，是把「无法判定是否该停」外包给模型的语感——语感在开放域里会系统性乐观。

处方：把停机写成显式状态机的一部分，而不是结尾附一句「如果你觉得可以了就停」。

一句话真相

好的 agent 不是更会动，而是每一步动作都绑定了可验证的进展定义；没有这条绑带，再强的模型也只是更贵的陀螺。

若你正在搭一条新流水线，先别写提示词——先画一张四格表：目标对象、步骤假设、反馈探针、停机规则。画完再写第一句 human message。