Agent 能力为什么会突然“飞跃”？
你肯定见过这种场面：
- Agent 规划写得像咨询报告 📝
- 真去执行，卡在第 2 步
- 然后开始编：工具明明没返回，它说“已完成”
这不是模型不够强，而是缺一层“可验证”的执行闭环。
很多论文/框架把 Agent 往“更会思考”方向推，但真正能让落地效果变猛的，往往是这件事：
每一步都要有验收标准；不满足就回滚重试；把过程记下来，下一次别再摔同一个坑。
下面咱们就按“能照做”的方式，把这套闭环搭起来。
你要的不是更长的计划，是「能验收的任务树」
常见错误：让 Agent 生成一个大计划，然后直接开跑。
真实世界不吃这一套。你需要的是任务树（Task Tree），每个节点都带：
- 输入：这一步拿到什么
- 动作：要调用什么工具/写什么代码/输出什么
- 验收：怎么判断完成（必须可检查）
- 失败策略：失败了怎么改、最多重试几次
✅ 任务节点模板（直接复制）
【任务节点】
目标：
输入：
动作：
产物：
验收标准（必须可检查）：
失败时调整：
重试次数上限：
示例：做一个“自动整理会议纪要”的 Agent
你别让它一句话“帮我整理纪要并输出待办”。拆成可验收的节点：
- 节点 A：提取发言人 + 关键结论
- 验收：发言人列表数量 > 0；每条结论有引用原句
- 节点 B：生成 TODO（带负责人/截止日期）
- 验收：每条 TODO 包含 3 个字段，不允许空
- 节点 C：导出 Markdown + 发到飞书/Slack
- 验收：接口返回 success；消息里包含标题
这时候 Agent 才像“项目经理”，不是“灵感写作者”。
核心组件 1：执行器（Executor）——每步只干一件事
执行器的规则很简单：
- 一次只执行一个节点
- 产物必须落盘（或进入状态存储）
- 每次工具调用都要保存原始返回
执行器输出格式（建议强制）
{
"step": "B",
"action": "generate_todos",
"inputs": {"summary": "..."},
"tool_calls": [{"tool": "none"}],
"output": {"todos": []}
}
你会发现一个好处：你能回放每一步。Agent 翻车时，不用猜。
核心组件 2：验收器（Verifier）——专门负责挑刺 😈
别让同一个“写的人”来“评自己”。人类都做不到，模型更做不到。
做法：给 Agent 配一个“验收人格”（可以是同一个模型的不同 system prompt，也可以是另一模型）。它只干一件事：
根据验收标准，判断 PASS/FAIL，并给出可执行的修改建议。
✅ Verifier 提示词模板
你是验收器，不负责创作。
你只根据【验收标准】检查【产物】。
输出必须是 JSON：
{
"result": "PASS"|"FAIL",
"reasons": ["..."],
"fix_suggestions": ["..."],
"missing_fields": ["..."]
}
验收标准：
{{criteria}}
产物：
{{artifact}}
验收标准怎么写才不废？
写“内容清晰、逻辑完整”这种，等于没写。
用这种：
- “每条 TODO 必须含：任务/负责人/截止时间；缺一项判 FAIL”
- “输出必须含 3 个小标题：结论、争议点、下一步；缺标题判 FAIL”
- “引用原句必须用
>，每条结论至少 1 条引用”
验收标准越像测试用例，Agent 越稳。
核心组件 3：回滚与重试（Rollback）——允许失败，但不允许装死
Agent 最烦人的不是失败，是失败了还硬说成功。
所以要加两条铁律：
- 验收 FAIL → 必须重试
- 重试要带“失败原因”上下文，不许从零开始瞎写
重试提示词（把失败原因塞回去）
刚才这一步验收失败。
失败原因：
{{reasons}}
修改建议：
{{fix_suggestions}}
请只针对问题修复，不要重写无关部分。
输出仍需满足原验收标准。
再加一个上限：比如每步最多 2～3 次。 超过就中止并报警，让人介入。
核心组件 4：过程记忆（Memory）——把“踩坑”变成资产
你想让 Agent 越用越好，就得记两类东西：
- 决策记忆：为什么这么拆任务、为什么选这个工具
- 错误记忆：常见失败模式 + 修复办法
建议的记忆结构
{
"project": "meeting_minutes",
"patterns": [
{
"symptom": "TODO 缺负责人",
"cause": "输入里没明确人名，模型偷懒",
"fix": "要求从原文提取负责人；提取不到就标记为待确认",
"prevention": "验收规则强制检查负责人字段"
}
]
}
场景感一点：
- 你下周再跑同样的“纪要 Agent”，它就不会再漏负责人
- 你每天能少手动补一次信息，真的能早下班一小时
一套最小可用的 Agent 闭环（代码骨架）
下面是偏伪代码的结构，重点是思路，你用 LangChain / 自己写都行。
MAX_RETRY = 3
for node in task_tree:
for attempt in range(MAX_RETRY):
artifact = executor.run(node)
verdict = verifier.check(node.criteria, artifact)
log.save(node, artifact, verdict)
if verdict["result"] == "PASS":
state.store(node.id, artifact)
break
node = node.apply_fix(verdict["fix_suggestions"]) # 把失败原因注入下一次
else:
raise RuntimeError(f"Node {node.id} failed after retries")
你会发现：这玩意儿看着“笨”，但交付会非常稳。
真实落地时最容易踩的坑（避坑清单）
- 验收标准写得太虚：验收器只能点头，无法挑错。改成字段级/格式级/数量级。
- 让执行器输出“自然语言”：后面无法做自动检查。强制 JSON 或可解析结构。
- 工具返回没保存：出问题只能靠猜。把原始返回存起来，日志是你的保险。
- 重试没有带失败原因：等于让 Agent 反复抽盲盒。把 reasons/fix_suggestions 贴回去。
- 同一模型同一提示词做执行+验收：经常互相放水。至少分角色提示词。
你可以从哪件小事开始改？
别一上来就“打造通用超级 Agent”。从你每天最痛的一个场景下手：
- 写周报、整理纪要、拉取数据出图、生成 PRD、批量改文案
做一件事就够：
把你的 Agent 输出，从“看起来对”变成“验收通过”。
闭环一旦跑顺，你会明显感觉 Agent 不是在“陪聊”，是在“交付”。
