如果让你设计一个 Agent，你会怎样设计？

核心回答

我会先确定 Agent 要替谁完成什么任务、交付什么结果、怎样判断完成，再设计运行闭环。以运维故障诊断助手为例，目标可以是根据服务和时间范围，整理日志、指标和操作手册中的证据，给出定位建议；是否执行变更要另外明确。

设计上抓五件事：

1. 目标与约束：明确输入、交付物、可访问系统，以及时间和调用预算；缺关键条件先澄清。
2. 决策与执行：模型根据当前证据选择下一步，程序校验动作并调用工具，再把结果交回模型。固定规则用代码处理，需要根据反馈变化的部分才交给 Agent。
3. 状态与知识：保存已确认条件、已完成步骤、证据和待验证假设；按需检索知识，而不是把所有历史都塞进提示词。
4. 验证与停止：检查工具结果和最终结论，证据充分就结束；无法推进或超过预算时，给出已知结果和缺口。
5. 评测与运行保障：用代表任务验证成功率、证据正确性、耗时和成本，并能追踪错误、重试和恢复。

先做一个可以完整验收的单 Agent 闭环，只有出现明确的职责或上下文隔离需求时，再考虑拆成多 Agent。

展开说明

1. 把需求转成可验收的任务

“做一个运维 Agent”还不够具体。我会先确定使用者、支持的系统、常见故障和允许的动作。例如第一版只做诊断：输入服务名称、环境、时间范围和现象，输出相关事实、可能原因、依据及下一步建议，不承诺每次都能确定根因。

完成标准也应具体：结论中的关键判断是否有日志、指标或文档支持，是否覆盖用户指定的服务和时间，是否明确哪些原因仍待验证。重启服务、修改配置等动作若需要支持，应建立相应工具权限和确认机制，不能由诊断请求自动推导出全部变更权限。

如果步骤已经固定，例如按既定模板汇总每日监控数据，普通程序或工作流可能足够。故障诊断的取证方向会随结果变化，才需要模型在循环中选择查什么。两者可以组合：入口校验、权限和最终结果格式由代码固定，取证与假设调整由 Agent 处理。

2. 用一条具体请求串起运行闭环

假设用户说“帮我看看订单服务刚才为什么出现大量 500”。先解析服务、环境和时间，缺失且无法从可信上下文确定的条件就澄清。

确定范围后，模型可以选择查询错误指标，程序把参数交给指标工具，得到带时间和来源的结果。若发现异常集中在某个依赖，下一步再查对应日志或链路；查到错误码后，可以检索相关故障手册。每次工具反馈都会改变当前证据和待验证假设，模型据此决定补查还是输出。

工具层应暴露清楚的名称、用途、参数和返回结构。例如日志工具接收服务、时间范围与受限查询条件，返回记录引用、摘要、是否截断和错误状态。模型提出调用意图，实际访问控制、参数校验、超时及结果处理由执行层负责。接口报错要作为错误反馈，不能包装成空数据让模型误判为“没有异常”。

最终汇总时，把已确认事实与可能原因分开。日志只显示某个下游超时，并不证明“下游机器宕机”；可以给出下一项验证建议，而不是为凑出确定根因继续无效调用。

3. 状态、上下文和记忆各承担什么

任务状态保存目标、已确认参数、执行阶段、工具结果引用、当前假设、错误及剩余预算，作为后续决策和恢复的依据。模型上下文则按当前步骤选择必要状态和相关证据，不必等于完整任务存档。

短期信息服务当前任务；需要跨任务保留的偏好或经过确认的经验可以单独存储，并考虑更新和失效。故障手册属于可检索的业务知识，当前日志和监控属于时效性数据，不能把一次旧任务结论长期当成当前事实。

上下文过长时，可以提取带来源的摘要，把大结果留在存储中按需读取。用户确认的条件、关键数字和相互矛盾的证据要保留，不能只压缩成一个没有出处的结论。

4. 规划和停止要受任务约束

简单请求可以逐步决策；较长任务可以先生成包含子目标、依赖和验收条件的计划，再根据工具反馈调整。计划是帮助控制任务的中间结果，不是生成后就必须照做的脚本。

对于模型调用数、工具调用数、耗时和费用设置总预算，工具自身也有超时与有限重试。重复调用时检查是否获得新证据；查询一个仍在处理的任务可能合理，反复查同一静态结果则可能没有进展。触及预算后收敛为部分结果、澄清或明确失败。

若一个 Agent 的工具和上下文已难以管理，或者任务确实包含独立专业子目标，再拆分专家。交接时要明确输入、输出和验收，不能期待多个角色互相聊天就自然完成协作。

5. 用什么证明设计有效

先选正常请求、缺条件、资料冲突、工具异常和无法回答等代表任务，建立简单程序或单模型方案作为基线。评测关注任务是否完成、证据和引用是否正确、工具参数是否正确，以及失败时是否给出有用的下一步；同时记录端到端平均与 P95 耗时、调用量和成本。

运行时保留任务标识、步骤、模型与工具版本、必要的输入输出和错误，便于定位是理解、检索、执行还是归并出了问题。长任务再配置可靠的检查点和恢复机制；外部写操作独立处理幂等及结果核对。先把这一条任务链路跑通，再根据实际失败原因改工具、模型或架构。

常见追问

模型怎样选？

先在目标任务上比较工具选择、参数生成、复杂证据理解、结构化输出和响应稳定性，再结合延迟、费用和部署要求选择。容易校验的提取步骤可以尝试较小模型，关键决策是否需要更强模型则看评测，不靠模型名称决定整套架构。

一定要独立的 Planner、Memory 和 Reflection 模块吗？

不一定。规划可以是一次决策中的短计划，状态存储可以先只服务当前任务；验证也可以由规则、工具和抽样人工检查共同承担。是否增加独立模块，要看它能解决什么具体失败、是否有可验收的收益。

框架在这个设计中负责什么？

可以复用框架的模型与工具接口、循环、图状态和检查点，把精力放在业务工具和任务契约上。若流程简单，自封装循环也可行；需要显式分支、人工输入和恢复时，图编排更容易表达这些要求。选框架前仍要清楚状态由谁保存、工具由谁执行，不能把业务验收交给框架名称代替。

对应教程

参考资料