Agent 架构与循环★★
从单次问答到自主完成任务
Workflow 路径写死，Agent 在每一步自己决定下一步——这是本质区别。
思考 → 行动 → 观察 → 判断是否结束——所有 Agent 的核心循环。
让 Agent 边想边做：每一步先写出 Thought，再决定 Action。
先列出完整任务计划，再逐步执行——适合复杂多步任务。
Agent 完成一轮后回头检查自己做得对不对，再决定要不要重来。
多个 Agent 分工合作（如 PM Agent + Coder Agent + Reviewer Agent）。
一个"主管" Agent 决定把任务交给哪个下属 Agent。
Agent 把任务转交给另一个 Agent，并带上必要的上下文。
Workflow 是开发者预先写死步骤和分支,系统按流程走;Agent 是模型在循环中根据目标、上下文和工具结果决定下一步。简单说,Workflow 强在稳定可控,Agent 强在面对开放任务时能动态规划。
- +能用 Workflow 解决的稳定业务流,不必硬上 Agent
- +Agent 的自由度越高,越要补上权限、预算、终止条件和可观测性
- +很多生产系统是混合形态:外层 Workflow 控流程,局部步骤用 Agent 决策
ReAct 是 Reasoning + Acting,也就是模型先思考下一步,再选择工具行动,拿到观察结果后继续推理。它把"想"和"做"交替起来,让模型能分步解决需要外部信息或操作的任务。
- +Observation 必须来自真实工具结果,不能让模型自己编一个观察
- +循环要设置最大步数、超时和失败退出,防止无限调用工具
- +日志里最好记录每次 action 和 observation,便于调试 Agent 行为
任务目标单一、工具边界清晰时,单 Agent 更简单可靠。任务天然有多个角色、需要并行探索或互相审查时,才考虑 Multi-Agent,例如规划者、执行者、审查者分工。
- +Multi-Agent 会增加通信成本、状态同步和责任归属问题
- +角色拆分要对应真实能力差异,不要只是把同一个 prompt 换几个名字
- +高价值场景是专家分工和交叉验证,不是为了架构看起来复杂
先从工程上设置硬边界:最大轮数、最大费用、超时和可取消。再从策略上检查目标是否模糊、工具反馈是否不可行动、是否缺少完成判定,必要时让模型总结当前状态并请求人工介入。
- +死循环常见原因是工具一直失败但模型没有失败分支
- +每轮循环都应记录状态变化,如果没有新信息就应触发停止条件
- +危险操作或高成本操作要有人工确认,不能让循环自动放大损失
Planning 让模型先把大目标拆成步骤,适合长任务、跨工具任务和需要回溯的任务。风险是计划可能一开始就错,后续执行会沿着错误方向越走越远,所以计划要能根据工具结果动态修正。
- +短任务不一定需要显式计划,否则会增加 token 和延迟
- +计划最好拆成可验证的小步骤,每步都有完成标准
- +计划与执行分离时,要处理执行反馈如何更新计划
Reflection 是让模型在阶段性结果后检查错误、补遗漏、决定是否重试。它适合代码生成、复杂推理和多步工具任务,但不能替代真实测试、规则校验或人工审核。
- +自我反思容易产生自信但错误的修正,关键结论仍要外部验证
- +反思触发要有成本意识,不必每一步都让模型复盘一遍
- +常见做法是执行失败后反思,或最终回答前做一次轻量检查
Orchestrator 负责拆任务、分派角色、维护共享状态、合并结果和处理失败。它像一个调度层,不一定自己完成业务任务,但要保证多个 Agent 的协作有边界、有顺序、有退出条件。
- +Orchestrator 可以是代码规则,也可以由模型参与决策,生产系统常两者结合
- +共享上下文要控制粒度,否则所有 Agent 都读全量信息会浪费且互相污染
- +结果合并不能只拼文本,要有冲突处理和质量检查
Handoff 是一个 Agent 或流程节点把任务交给另一个更合适的角色,常见于客服转人工、规划转执行、研究转写作。避免丢信息的关键是传递结构化任务摘要、已尝试动作、关键证据和下一步预期。
- +交接内容不应只是一段聊天记录,最好有状态字段和决策理由
- +接收方要知道自己权限和目标,否则会重复前一个 Agent 的工作
- +复杂系统要记录 handoff 链路,方便追踪责任和定位错误