18.2 工作流与 Agent：工具、循环和权限边界

固定工作流由代码决定步骤；Agent 让模型根据目标和环境反馈动态选择下一步。后者适合路径难以预先枚举的任务，但会增加延迟、成本和不可预测性。

优先使用能完成任务的最简单结构：单次模型调用、检索增强、固定链路、带分支的工作流，最后才是开放循环。复杂度应由评估结果推动。

常见工作流

Prompt chaining

把可清楚分解的任务串联，并在中间增加程序化检查：

抽取事实 → schema 校验 → 生成草稿 → 引用检查

Routing

先分类，再交给专门提示、工具或模型。路由器需要独立评估误路由成本，并提供低置信度兜底。

Parallelization

独立子任务可并行处理后聚合；同一任务多次采样可用于候选比较。只有当额外调用确实提高目标指标时，才值得支付成本。

Evaluator–optimizer

生成器根据明确标准反复修订。必须设置最大轮数和停止条件，避免把“评价者还能提出意见”误当作持续改进。

Agent 是一个受控循环

概念上的运行时：

目标 + 当前状态
      ↓
模型选择回答或工具调用
      ↓
策略检查 / 必要时审批
      ↓
执行工具并记录观察
      └──────────→ 下一轮

ReAct 论文展示了推理与行动交替的范式。工程实现不需要向用户暴露或永久保存模型的私有推理文本；应按最小必要原则保存可审计的计划摘要、脱敏工具参数与结果、批准记录和最终产物。

循环必须有退出条件：成功、明确失败、需要用户输入、权限不足、达到步数/时间/费用预算，或连续没有进展。“成功”应由目标产物或权威状态检查确认，不能只因为模型决定输出一句“完成”。

工具定义决定 Agent 的能力边界

工具应具备：

• 可区分的用途、清楚的参数 schema 和前置条件；
• 结构化返回值与可分类错误；
• 最小权限和调用方身份传播；
• 幂等键或可查询操作状态；
• 超时、速率限制和审计日志；
• 按现有授权与动作风险决定是否需要额外批准的机制。

“执行 SQL”或“调用任意 URL”权限过宽。更安全的工具是 getOrder(id)、requestRefund(orderId, amount, reason)，由应用代码继续执行授权、限额和不变量。

模型提出工具调用不等于已获授权。权限在服务端根据用户、租户、资源和动作重新判断。若动作需要批准，批准记录应绑定具体资源、参数、权限范围和有效期；批准后金额从 100 改成 1000，就不再是同一个被批准的动作。

以退款为例，执行前持久化操作 ID 和意图，执行后记录工具回执。若外部退款已成功但进程在记回执前崩溃，恢复时先按同一操作 ID 查询或幂等重试，不能生成新 ID 再扣一次。只把聊天消息存进数据库，还不足以实现这种可恢复执行。

Prompt Injection 是控制流攻击

网页、邮件和检索文档中的文本可能要求 Agent 泄露秘密或调用工具。外部内容是数据，不是可信系统指令。

防护需要多层组合：

• 把可信指令与不可信内容明确分隔；
• 对工具实施最小权限和参数验证；
• 对需要新增授权的高风险动作，确认时展示真实参数；
• 不把不必要的密钥放入模型上下文；
• 对读取、写入、发送和支付等能力分级授权；
• 用对抗测试持续检验，而不是只靠一句“忽略恶意指令”。

状态、记忆与上下文不是同义词

• 运行状态：当前步骤、工具结果、批准和预算；
• 会话上下文：本次交互需要提供给模型的信息；
• 长期记忆：跨会话保留、可检索的信息；
• 业务真相：订单、权限、余额等权威系统记录。

长期记忆必须有来源、范围、更新、删除和隐私政策。恢复运行时还要检查已保存批准是否过期、用户权限是否变化，不能把昨日的上下文当作今日的通行证。模型生成的摘要不能自动升级为业务真相。

多 Agent 只在责任边界清楚时使用

增加 Agent 会增加交接、上下文丢失、循环和评估组合。适合拆分的信号是工具权限、专业指令或结果所有者确实不同，而不是“角色越多越聪明”。

无论采用 handoff 还是把 Agent 当工具调用，都要明确：谁拥有最终回答，谁可以执行副作用，失败后控制权回到哪里。

下一课建立评估和运行治理，使模型、提示、检索器或工具变化可以被量化比较。

参考资料

• Anthropic, Building effective agents
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models
• OpenAI, Agents SDK