最近在做 Agent，我看了不少别人写的 Skill。
有些 Skill 规则很全，脚本也不少，跑起来却总在奇怪的地方卡住。回头看它刚才一步步做了什么，问题经常出在同一个地方：作者写清了 Agent 要做什么，却没想过这一步做完以后，Agent 会看到什么，又该怎么继续。
要说清楚这个问题，得先说 ReAct。
先看一盏不亮的灯
先把 Agent 想成一个会使用工具的维修员。你对它说：帮我看看这盏灯为什么不亮。
灯不亮，可能是灯泡松了，也可能是灯泡坏了，还可能是灯座没有电。Agent 现在只有几种猜测，没有答案。
它先从最容易检查的地方开始：
Thought：先检查灯泡有没有松。
Action：把灯泡拧紧，再打开开关。
Observation：灯还是不亮。这个结果排除了“灯泡没拧紧”。下一轮，它要区分是灯泡坏了，还是灯座没有电：
Thought：换一只确认能用的灯泡试试。
Action：换上新灯泡，再打开开关。
Observation：灯亮了。现在它可以得出一个更可靠的判断：灯座能供电，原来的灯泡坏了。
Agent 一开始不知道答案。它先选一个可能的原因去检查，再根据结果决定下一步。每拿到一个观察结果，猜测就少一点，下一步也会更具体。
Agent 到底在循环什么
ReAct 是姚顺雨在他那篇论文里提出来的。它让模型在三件事之间来回走：先判断下一步，再去查或者去做，最后拿回外部结果。
论文里把这三步叫作 Thought、Action 和 Observation，也就是思考、行动和返回结果。返回结果会进入下一轮思考，改变 Agent 接下来要做的事。
拿刚才那盏灯来说，Agent 每试一次，就多排除一种可能，再决定下一步试什么。它循环的不是同一个动作，而是“判断、行动、根据结果重新判断”。
实际产品里，这些步骤不一定一行行展示出来，工具也可能同时调用多个。但 Agent 能不能继续往前走，仍然取决于刚才那一步返回了什么。
很多 Skill 只写到了行动
这也是我最近看 Skill 时反复碰到的问题。
很多脚本正常时能干活，一出错，却只扔回来一段系统异常：
{
"error": "ENOENT",
"path": "/tmp/input.md"
}JSON 只是一种方便机器读取的格式，本身没有问题。问题是，这段内容只告诉开发者系统哪里坏了。Agent 仍然不知道该换路径、向用户要文件，还是直接重试。
如果它返回的是：
{
"status": "blocked",
"reason": "没有找到要处理的文件",
"next_action": "请用户提供文件，收到后重新执行",
"retryable": true
}Agent 看到后一段，就知道自己卡在哪里，也知道该向用户要文件，拿到以后再试。下一轮思考就有路可走了。
对 Agent 来说，报错不是日志，是下一轮推理的输入。
写 Skill 时，我现在会多问一个问题
以前检查 Skill，我会看规则有没有写全，脚本能不能跑，输出格式对不对。
现在还会多问一句：
这个动作执行完以后，Agent 知道下一步干什么吗？
成功了，就告诉它拿到了什么。失败了，要说缺什么、能不能重试、该换哪个动作。如果只做完一部分，也得告诉它还有什么没做。
如果它返回的结果不能告诉 Agent 接下来怎么走，这个 ReAct 循环就只转了半圈。
本文由作者【YannTalk】，微信公众号：【YannTalk】，原创或授权 发布于平台，未经许可，禁止转载。