Agent：从一次回答到多步行动

本章路线图

Agent 不是一个单独模型，而是“模型决策 + 工具执行 + 状态管理 + 控制循环”的系统。本章把它还原为可测试的状态机，并重点说明权限、失败恢复和人工确认。

Agent 的最小闭环是什么

一个最小 Agent 会接收目标与当前状态，决定下一步动作；若需要外部能力，就生成结构化工具调用；系统执行工具并返回结果；模型再观察结果，继续行动或给出最终答案。

它的核心不是“像人”，而是模型、工具、状态和循环控制组成的系统。没有可靠工具和停止条件，再强的模型也只会把不确定性放大。

Workflow 和 Agent 不要混为一谈

Workflow 的步骤主要由开发者预先确定，适合稳定、可审计的流程；Agent 让模型动态选择步骤，适合路径难以穷举的任务。实际产品通常是混合方式：关键边界固定，局部选择交给模型。

能用确定代码解决的步骤，不必都交给模型。动态性越高，测试空间、成本和安全风险越大。

工具调用为什么需要严格协议

工具定义要写清名称、用途、参数类型和约束；模型只负责提出调用，真正执行由宿主系统完成。参数必须校验，超时和错误要结构化返回，副作用操作还要确认权限与幂等性。

不要把网页或工具返回的文本当成可信指令。外部内容可能包含提示注入；系统应隔离数据与控制信息，只向工具开放完成任务必需的最小权限。

Memory、计划与停止条件

短期状态记录当前步骤和工具结果；长期记忆应保存经过筛选的稳定事实，而不是无限堆积对话。把所有历史都塞回上下文会增加成本、噪声和隐私风险。

循环要有最大步数、预算、超时、重复检测和人工接管条件。评估不能只看最终文字，还要看工具是否选对、参数是否正确、步骤是否必要、失败能否恢复。

把 Agent 写成状态机

最小状态可以包含用户目标、已知事实、待执行步骤、工具结果、预算和终止原因。每轮只允许发生有限状态转移：

接收目标 → 判断下一步 → 请求工具 / 请求用户 / 输出答案
              ↑              ↓
              └──── 观察结果并更新状态

显式状态让系统能够暂停、恢复、重试和审计。若全部状态只存在模型自然语言中，一次上下文截断或格式变化就可能让任务失控。

Tool Schema 是能力边界

工具定义应说明名称、用途、参数类型、必填项和返回结构。优先使用枚举、数值范围和结构化对象，避免让模型拼接任意命令字符串。

{
  "name": "get_order",
  "arguments": { "order_id": "A-1024" }
}

系统必须在执行前独立校验参数、身份与权限。模型生成了合法 JSON，只代表格式正确，不代表操作已获授权。

Workflow、Router 与开放式 Agent

确定性 workflow 由程序固定步骤，模型只负责某些节点；router 根据输入选择预设分支；开放式 Agent 则可以动态决定多步动作。

任务规则稳定、风险高或必须可预测时，优先 workflow。只有当路径确实难以提前枚举，并且动态规划的收益大于不确定性时，才增加 Agent 自主度。

很多所谓 Agent 产品实际上是“模型路由 + 几个工具 + 固定循环”，这种结构通常更容易测试和上线。

规划、执行与反思

计划可以一次生成，也可以每步重规划。长计划容易在早期假设错误后整体失效；逐步规划更灵活，却增加调用与漂移风险。实用做法是保留短计划和明确下一步，每次工具结果后重新检查。

“反思”只有在能引入新证据、验证器或错误信号时才有价值。让模型反复评价自己的答案，可能只是以更多 Token 重复同一偏差。

Memory 应保存什么

• 工作记忆：当前任务步骤、临时变量和工具结果。
• 会话记忆：本次对话中仍相关的事实与用户约束。
• 长期记忆：经过确认、可更新且有来源的稳定偏好或事实。

长期记忆必须有写入条件、来源、有效期、修改和删除机制。原始对话不能自动视为永久事实；敏感信息也不应为了“个性化”无限保存。

检索记忆时同样需要权限、相关性和冲突处理。新旧事实冲突时应请求确认，而不是静默选择一条。

错误、重试与幂等性

工具失败可能来自参数错误、暂时超时、权限不足、业务拒绝或部分成功。系统应返回结构化错误类型，让 Agent 决定修正参数、稍后重试或请求用户。

重试写操作必须考虑幂等性。支付、发消息、创建工单等工具应支持 idempotency key，避免超时后重复执行。对于已发生部分副作用的步骤，要有补偿动作或明确人工处理。

人工确认放在哪里

读取公开信息通常风险低；发送消息、修改数据、付费、删除、授权和对外发布属于高影响动作，应在执行前展示目标、参数和后果并等待确认。

确认必须绑定具体动作，不能用一次宽泛许可覆盖后续未知操作。系统还应防止模型把工具返回的恶意文本变成新的高权限指令。

提示注入与最小权限

网页、邮件和文档都是不可信数据，可能包含“忽略之前规则”等提示注入。系统应区分控制指令与外部内容，不把工具结果拼接成同级系统指令。

每个工具只开放完成任务所需的最小范围：限定资源、字段、操作和速率；秘密由执行层管理，不直接暴露给模型。跨用户或跨租户数据在进入上下文前完成隔离。

可观测性与回放

一次 Agent 运行应记录模型版本、提示版本、每步输入摘要、工具名、校验后的参数、结果状态、耗时、Token、成本与终止原因，同时对敏感字段脱敏。

可回放轨迹能区分规划错误、工具错误和环境变化。生产调试不应依赖一段最终答案，因为最终成功也可能隐藏多次无谓调用或危险尝试。

怎样评测 Agent

最终任务成功率是主指标，但还需拆解：工具选择准确率、参数正确率、步骤数、重试率、权限违规、恢复能力、延迟和成本。

测试集应包含正常任务、缺少信息、工具超时、返回冲突、恶意网页、需要确认与无法完成的情况。评测环境要隔离真实副作用，写操作使用沙箱或模拟器。

一个可靠的 Agent 架构

用户目标
  ↓
策略与权限层 ──→ 人工确认
  ↓
模型决策层
  ↓ 结构化调用
工具执行与参数校验
  ↓
状态存储、日志与预算控制
  └────────→ 下一轮或终止

模型只是决策组件之一。权限、状态和执行可靠性由确定性系统承担，才能把概率模型放进真实业务。

常见误区

• 工具越多不一定越强，选择难度和攻击面会同时增加。
• 更长思维过程不等于更可靠的计划。
• Memory 不是无限对话历史。
• 自动重试不适用于所有有副作用操作。
• 最终答案看起来正确，不能证明中间动作合规。

章末检查

1. 把一个“查询订单并申请退款”的任务画成状态机。
2. 哪些步骤可自动执行，哪些必须请求确认？
3. 工具超时后怎样判断能否安全重试？
4. 外部网页中的指令为什么不能直接控制 Agent？
5. 除最终成功率外，还应记录哪些轨迹指标？

延伸资料

• ReAct
• Toolformer
• OWASP Top 10 for LLM Applications