Agent 工作流设计模式：规划、工具和人工复核

很多 Agent Demo 看起来失败，是因为模型不够聪明；但进入真实项目后，更常见的根因是流程没有状态。系统不知道输入解析到哪一步、计划是否被确认、工具是否执行过、失败原因是否已经反馈。

CAD 转 3D Agent 里，如果 DXF 解析、建模计划、Blender 执行和结果验证混在一次对话里，失败时只能猜是图纸问题、prompt 问题还是工具问题。把这些信息写进状态，才有复盘和重试的基础。

Agent 工作流最容易失控的地方，是把所有职责都塞进一个大 prompt。模型既要理解输入，又要规划步骤，还要决定工具，还要判断结果是否合格，最后很难知道错误出在哪里。

更稳的方式是先拆状态：输入解析、计划生成、人工确认、工具执行、结果验证。每个状态都有明确输入和输出，失败时也能知道应该回到哪里。

1. 01

   Parse

   把原始输入整理成可供模型和工具使用的结构。

2. 02

   Plan

   把意图转成可审查的执行计划。

3. 03

   Confirm

   在高成本动作前插入人工复核。

4. 04

   Execute

   只执行已经确认的工具动作。

5. 05

   Validate

   检查结果并把失败原因写回状态。

规划节点不能只输出一段自然语言建议。真正能接工具的规划，应该产生结构化动作，比如创建墙体、放置门窗、设置材质、保存文件、触发验证。

• 动作名称要稳定，方便执行器路由到具体工具。
• 参数要能被校验，避免错误延迟到工具层才暴露。
• 计划要能被人工修改，而不是只能整体接受或拒绝。

工具选择不是把所有 API 都暴露给模型。模型能调用什么，应该由当前状态和业务规则决定。

1. 确认阶段只允许审查计划，不允许直接执行。
2. 执行阶段只接收结构化动作，不重新解释用户意图。
3. 验证阶段可以读取结果，但不应该修改原始输入。

这也是工具抽象的意义：Agent 层只知道有一个 BlenderTool，至于底层是 Background 还是 MCP 适配器，可以在不改流程的情况下替换。

很多项目把 human-in-the-loop 理解成“让用户点一下确认”，但真正有价值的是确认前后状态怎么变化。用户批准、修改、重做和取消，应该进入不同路径。

• 批准后进入执行。
• 修改后更新计划并保留变更痕迹。
• 重做后回到规划节点。
• 取消后停止高成本操作。

人工复核的重点是让关键风险停在可判断的位置。

Agent 不是执行完就结束。真实流程里还需要验证结果是否符合输入、是否满足业务规则、是否需要回到规划阶段。

硬校验

实体、尺寸、文件

检查数量、坐标、输出文件和执行结果是否存在。

软校验

语义合理性

复核结果是否符合建筑常识和用户输入意图。

一旦验证失败，反馈要回到规划节点，而不是只给用户一句错误。这样 Agent 才从一次生成变成可迭代流程。

1. 每个节点是否有明确输入、输出和失败原因。
2. 规划结果是否是结构化动作，而不是一段不可执行建议。
3. 工具权限是否跟随当前状态变化，而不是全部暴露给模型。
4. 人工复核是否能批准、修改、重做和取消，并留下状态记录。
5. 验证失败是否能回到可修正节点，而不是只返回一条错误信息。

这份清单的目的不是让 Agent 看起来更复杂，而是让它在真实业务里更容易解释。只要其中一项缺失，后续调试通常都会退回到“重新改 prompt”的低效循环。

对应项目是 CAD 图纸转 3D 模型 AI Agent。项目页展示的是 LangGraph 工作流、DXF 输入解析、Blender 工具抽象和人工确认路径；这篇笔记补充的是为什么这些边界比一次性生成更重要。

流程证据

Parse / Plan / Confirm / Execute / Validate

用状态节点解释 Agent 如何从图纸输入走到可复核输出。

业务边界

人工确认 + 工具权限

把高成本建模动作停在可判断的位置，避免模型直接执行不可控操作。

一个 Agent 项目不应该只证明“模型能跑一次”。更有价值的是展示这些能力能迁移到其他业务：状态建模、工具权限、人工复核、验证闭环和失败复盘。

• 状态设计说明流程是否可维护。
• 工具抽象说明执行层是否可替换。
• 人工复核说明风险是否被控制。
• 验证闭环说明结果是否能持续改进。