一句话定义
Agent 是一个循环：模型观察当前状态，决定下一步动作，调用工具执行，把结果加回上下文，再决定下一步。重复直到任务完成、失败或达到步数上限。
和 工作流 的区别在于：工作流的步骤是事先确定的，Agent 的步骤是运行时决定的。
为什么重要
它把模型从「一次问答」推进到「完成一件事」。
工作流能处理可预测的任务，但真实的业务任务往往需要根据中间结果调整路径——查不到客户记录，就得换个字段再查；代码报错，就得读错误信息再改。这种动态性只能由循环提供。
同时，Agent 也是当前可靠性的主要来源。绝大多数 Agent 失败，不是模型不够聪明，而是循环、工具与状态管理没设计好。
最小可用结构
while 未完成 and 步数 < 上限:
response = model(messages, tools)
if response 是最终回答: break
result = 执行工具(response.tool_calls)
messages.append(result)就这么简单。所有复杂性都来自这三行之外的工程问题。
真正的难点
| 问题 | 表现 | 对策 |
|---|---|---|
| 目标漂移 | 做到一半忘了原始需求 | 每轮重申目标；关键约束写进系统提示 |
| 循环失败 | 反复调用同一工具 | 检测重复动作；在结果中明确「无更多数据」 |
| 上下文爆炸 | 步数一多就超限或变贵 | 压缩历史、只保留结论与关键观测 |
| 错误累积 | 一步错步步错 | 关键节点做校验；失败可回滚 |
| 权限越界 | 做了不该做的操作 | 写操作需确认；权限最小化 |
| 无法评估 | 不知道是否变好 | 固定任务集做回归测试 |
设计原则
- 先试工作流。如果流程图能画出来，就不要用 Agent。
- 工具宁少勿多。每个工具都要有清晰的触发条件。
- 给明确的终止条件。既包括成功，也包括「确定做不到，应该放弃」。
- 不可逆操作必须有人确认。这是底线，不是可选项。
- 记录完整轨迹。没有轨迹就无法调试，也无法改进。
常见的过度设计
- 一上来就做多 Agent 协作。多数场景下，单 Agent + 好工具优于多个 Agent 互相通信。
- 引入复杂的规划模块。让模型在循环里边做边调整通常更有效。
- 追求完全自主。在关键节点设置人类检查点，反而能提高整体效率。
常见误解
- 「Agent 就是更聪明的聊天机器人」：本质区别在于它能产生副作用——它真的会改变外部世界。
- 「自主性越高越好」：自主性和可靠性通常成反比。好的设计是在需要的地方才放权。
- 「模型够强就不需要工程」：模型能力提升会抬高上限，但循环、工具、状态管理仍然决定下限。
延伸阅读
- Tool Calling：Agent 的手
- Agent Harness：Agent 的躯干
- Evals：如何判断 Agent 有没有变好