ReAct / Toolformer 与 Agent 底层逻辑解读

Source anchors

• ReAct paper: https://arxiv.org/abs/2210.03629
• Toolformer paper: https://arxiv.org/abs/2302.04761

读这组论文的目标: PM/BA/架构师分别要学到什么

这组论文不是只讲 prompt 技巧，而是在解释大模型从“文本生成器”走向“可执行任务系统”的底层转变。 PM 要学到的是：Agent 产品不是把聊天框接到几个 API 上，而是把用户目标、工具边界、任务状态、风险控制、失败恢复和人类审批设计成一个可运营的产品流程。 BA 要学到的是：Agent 需求不能只写“系统自动处理”。必须拆成可观察的业务状态、可调用的动作、可验证的输出、异常分支、权限约束、审计字段和人工介入规则。 架构师要学到的是：Agent 不是一个单体模型服务，而是一套由模型、工具网关、工作流引擎、策略引擎、记忆层、审计层、评测层、监控层共同构成的行动系统。 ReAct 的价值在于给出“思考-行动-观察”的运行范式。 Toolformer 的价值在于说明“模型可以学会在合适时机调用工具”，而不是每一步都靠人工规则硬编码。 二者合起来，构成今天企业 Agent 架构的两个根基：

1. 运行时循环：模型如何在环境反馈中推进任务。
2. 工具使用能力：模型如何判断何时调用什么工具、传什么参数、如何吸收返回结果。 对金融零售场景尤其重要的是：Agent 一旦能行动，就进入了风控、合规、操作风险、客户权益和审计责任的范围。 因此，本笔记的核心不是“如何让 Agent 更聪明”，而是“如何让 Agent 可控、可验证、可治理地执行业务任务”。

From language model to action system: why generation alone is not enough

纯语言模型擅长根据上下文生成下一个 token。 这足以完成摘要、改写、分类、问答草稿、邮件生成等低风险任务。 但企业真实业务并不是静态文本生成。 真实业务有外部状态：客户账户余额、交易状态、工单进度、监管规则、库存、支付路由、黑名单、合同条款。 真实业务有行动后果：冻结账户、退款、发起调查、升级工单、通知客户、提交合规报告。 真实业务有时效要求：SLA、付款截止、争议处理时限、监管申报窗口。 真实业务有权限边界：谁可以看什么数据，谁可以执行什么动作，什么动作必须双人复核。 真实业务还有不可逆动作：放款、清算、拒付、客户通知、监管提交、删除记录。 如果模型只生成文本，它最多是“建议系统”。 如果模型能调用工具、读取观察、更新计划、触发动作，它才变成“行动系统”。 这也是为什么 Agent 不能简单等同于 Chatbot。 Chatbot 的主要输出是回答。 Agent 的主要输出是状态变化。 一个成熟 Agent 需要回答三个问题：

1. 当前目标是什么？
2. 当前世界状态是什么？
3. 下一步可允许的动作是什么？ 生成本身不解决事实新鲜度。 生成本身不解决计算精确性。 生成本身不解决跨系统状态同步。 生成本身不解决权限和审批。 生成本身不解决循环、成本、超时和失败恢复。 ReAct 和 Toolformer 正是在这些缺口上建立 Agent 的基础。

ReAct core idea: reasoning + acting + observation loop

ReAct 的核心是把 reasoning 和 acting 交错起来，而不是先完整推理再执行，或只执行不解释。 一个典型 ReAct 轨迹可以抽象成：

Thought: 我需要先确认事实或当前状态。
Action: 调用某个工具或执行某个环境动作。
Observation: 工具或环境返回结果。
Thought: 基于观察更新判断、计划或下一步。
Action: 继续检索、计算、执行或结束。
Observation: 获得新反馈。
Finish: 输出答案或完成任务。

这里的关键不是“模型把推理过程写出来”，而是“推理和外部观察互相校正”。 ReAct 论文展示了两类价值。 第一类是知识密集型任务。 模型不是只依赖内部记忆回答问题，而是通过搜索、查找、结束等动作获取外部证据。 这降低了幻觉和错误传播。 第二类是交互式决策任务。 模型需要在环境中一步步行动，例如网页导航、文本游戏、购物任务。 如果只生成动作，模型容易重复错误动作。 如果有语言化的中间思考，模型可以记录目标、识别异常、调整路径。 ReAct 对企业 Agent 的启发是：

1. 每次行动前要有可解释的意图。
2. 每次行动后要有可记录的观察。
3. 下一步不能只依赖原始 prompt，而要依赖累计轨迹。
4. 当观察与预期不一致时，Agent 必须能改变计划。
5. 结束条件必须显式，而不是让模型无限继续。 对 PM 来说，ReAct 是任务体验设计。 用户看到的不只是回答，而是“系统正在查什么、为什么查、下一步要做什么、是否需要确认”。 对 BA 来说，ReAct 是需求分解方法。 每个业务流程都可以拆成目标、动作、观察、判断、异常和结束。 对架构师来说，ReAct 是运行时编排模式。 模型只是循环中的决策组件，不应该直接拥有所有系统权限。

Toolformer core idea: models learning to call tools, API call examples, self-supervised tool-use intuition

Toolformer 关注另一个问题：模型如何学会使用工具。 它观察到大模型虽然擅长语言任务，但在算术、事实查询、日期、翻译等问题上经常不如专门工具。 解决方案不是让模型记住一切，而是让模型学会在需要时调用外部 API。 Toolformer 的关键思想包括：

1. 工具输入和输出都表示成文本。
2. 给每种工具少量调用示例。
3. 让模型在大量普通文本中尝试插入 API 调用。
4. 执行这些 API 调用，得到返回结果。
5. 只保留那些能帮助模型更好预测后续文本的调用。
6. 用插入了有效 API 调用的数据继续训练模型。 这是一种自监督直觉。 模型不是靠人给每个样本标注“这里应该调计算器”。 模型先提出候选调用，再用“这个调用结果是否降低后续预测损失”来筛选。 如果调用工具后的结果让后续文本更容易预测，说明这个工具调用有用。 这种思想对企业系统非常重要。 它说明工具使用不应该全靠静态规则。 未来的 Agent 会越来越会自己判断：
7. 什么时候需要查客户资料。
8. 什么时候需要调用规则库。
9. 什么时候需要计算费用。
10. 什么时候需要搜索政策。
11. 什么时候需要提交审批。 但 Toolformer 也提醒我们：能学会调用工具，不等于可以无约束调用工具。 论文里的工具多是低风险工具，例如计算器、问答、搜索、翻译、日历。 企业工具可能直接改变客户权益和账务状态。 因此，Toolformer 的产品化版本必须加上权限、策略、审批、审计和回滚设计。

API call examples

以下是面向金融零售 Agent 的示意格式。

客户本月跨境交易手续费为 [Calculator("120000 * 0.015") -> "1800"] 1800 元。

根据政策库，[PolicySearch("Reg E dispute provisional credit deadline") -> "10 business days for many consumer disputes"] 该争议需要检查临时入账时限。

客户身份校验状态为 [KycStatus(customer_id="C123") -> "verified"]，可进入下一步争议受理。

该商户近 30 天拒付率为 [MerchantRisk(merchant_id="M88", window="30d") -> "2.7%, above threshold"]，需要升级人工复核。

这些例子体现三个设计点：

1. API 调用应该结构化，而不是自然语言随意拼接。
2. API 返回应该简短、可解析、可审计。
3. 模型使用返回结果时，应保留来源和时间。

Agent mental model: goal, state, plan, action, tool, observation, memory, stop condition, human approval

企业 Agent 可以用十个概念理解。 Goal 是目标。 目标必须来自用户、系统事件或业务规则，而不是模型自发创造。 目标应有范围，例如“调查这笔交易是否需要升级”，而不是“解决客户所有问题”。 State 是状态。 状态包括输入数据、当前任务阶段、已知事实、未决问题、权限上下文和执行历史。 Plan 是计划。 计划是任务分解，不是承诺。 Agent 应该能在观察变化后修改计划。 Action 是动作。 动作可能是读数据、写数据、调用模型、调用 API、发通知、创建工单、请求审批。 Tool 是动作的实现接口。 工具应该有 schema、权限、超时、幂等键、审计日志和错误语义。 Observation 是行动后的反馈。 观察不是模型臆测，而是来自工具、环境、人或系统事件的返回。 Memory 是记忆。 短期记忆保存当前任务轨迹。 长期记忆保存可复用事实、偏好、案例、政策片段或历史决策。 Stop condition 是停止条件。 停止条件包括目标完成、风险过高、预算耗尽、达到最大步数、需要人工审批、外部依赖不可用。 Human approval 是人工批准。 人工批准不是最后加一个按钮，而是嵌入到高风险动作前的策略节点。 一个 Agent 只有同时具备这些概念，才从“会聊天的模型”变成“可治理的业务执行单元”。

Enterprise agent architecture: workflow engine, tool gateway, policy engine, audit trail, eval, observability, HITL

企业 Agent 架构建议分层设计。 第一层是用户入口或事件入口。 入口可能是客服对话、运营后台、邮件队列、案件系统、支付异常事件、监管变更通知。 第二层是 Agent runtime。 它负责保存目标、上下文、轨迹、步骤预算、模型调用、工具调用和停止判断。 第三层是 workflow engine。 工作流引擎负责把业务流程显式化，例如 AML 案件初筛、争议处理、支付异常排查、IT 工单处理。 工作流不应完全交给模型自由发挥。 可预测流程应由工作流控制。 需要判断、生成、检索、归纳的节点才交给模型。 第四层是 tool gateway。 工具网关统一封装所有外部系统调用。 模型不能直接访问核心系统数据库或任意内部 API。 工具网关负责 schema 校验、权限检查、速率限制、脱敏、超时、重试、审计和熔断。 第五层是 policy engine。 策略引擎负责判断某个动作是否允许。 例如“退款超过 500 美元需要人工审批”，“冻结账户必须有风险规则命中”，“客户 PII 只能在授权场景访问”。 第六层是 audit trail。 审计轨迹必须记录输入、模型版本、提示模板版本、工具调用、返回摘要、决策理由、人工审批、最终状态。 第七层是 eval。 Eval 不只是模型准确率。 它要评估任务成功率、错误动作率、越权率、幻觉率、人工接管率、SLA、成本、客户影响和合规风险。 第八层是 observability。 可观测性要覆盖 token、延迟、工具错误、循环次数、重试次数、失败原因、异常路径、成本分布。 第九层是 HITL。 Human-in-the-loop 不是人工兜底口号，而是一组明确机制：

1. 何时必须人工确认。
2. 人工看到什么证据。
3. 人工能修改哪些字段。
4. 人工决定如何回写系统。
5. 人工反馈如何进入评测和改进。

Agent patterns: planner-executor, supervisor, single-agent, multi-agent, event-driven, background agents

Planner-executor 模式把计划和执行拆开。 Planner 负责分解任务、选择路径、识别依赖。 Executor 负责调用工具、收集结果、执行步骤。 适合复杂调查、跨系统排障、合规影响分析。 Supervisor 模式增加一个监督者。 Supervisor 负责检查子 Agent 输出、决定是否继续、升级或停止。 适合高风险流程，例如 AML、欺诈、合规审查。 Single-agent 模式由一个 Agent 完成端到端任务。 适合低风险、短链路、工具少的场景，例如 IT helpdesk FAQ、内部知识检索、简单工单分类。 Multi-agent 模式由多个专业 Agent 分工。 例如一个 Agent 查交易，一个 Agent 查客户，一个 Agent 查政策，一个 Agent 汇总建议。 它适合知识域差异大、任务可并行的场景。 但多 Agent 会带来协调成本、状态一致性、责任归属和调试复杂度。 Event-driven 模式由事件触发。 例如支付失败、KYC 状态变化、监管规则更新、商户拒付率异常。 Agent 不等用户提问，而是在事件到达后启动工作流。 Background agents 是后台持续运行的 Agent。 它们适合监控、巡检、资料补全、异常预警、政策变更扫描。 后台 Agent 必须有更严格的预算、频率、权限和告警机制。 模式选择原则：

1. 低风险短流程优先 single-agent。
2. 高风险决策引入 supervisor。
3. 强流程合规场景用 workflow engine 主导。
4. 长周期监控用 event-driven 和 background agents。
5. 不要为了显得先进而默认 multi-agent。

Tool design: schema, permissions, idempotency, timeout, retries, audit, irreversible actions

工具设计是 Agent 成败的核心。 模型再强，如果工具边界混乱，系统仍然不可靠。 Schema 要明确。 输入字段要有类型、枚举、范围、必填、默认值和业务含义。 输出字段要稳定，避免每次返回一段不可解析的自然语言。 Permissions 要最小化。 Agent 的工具权限应基于角色、任务类型、客户授权、数据分类和风险等级动态计算。 Idempotency 要内建。 任何写操作都应支持幂等键，避免模型重试导致重复退款、重复通知、重复建单。 Timeout 要显式。 工具超时后不能让模型无限等待或反复调用。 Retries 要受控。 只对可重试错误重试，例如网络抖动。 对业务拒绝、权限不足、校验失败不应盲目重试。 Audit 要默认开启。 每次工具调用都要记录调用者、任务、参数摘要、权限判断、返回摘要、耗时、结果码。 Irreversible actions 要隔离。 不可逆动作包括付款、退款、冻结、解冻、客户通知、监管提交、删除记录。 这些动作应使用专门工具，默认需要审批、二次确认或双人复核。 一个健康的工具设计原则是：让模型选择业务动作，但让系统控制动作边界。

Failure modes: tool misuse, loop, stale observation, hidden state, prompt injection, unauthorized action, cost explosion

Tool misuse 是工具误用。 例如本该查政策却查知识库，本该计算金额却让模型心算，本该只读却调用写接口。 Loop 是循环。 Agent 反复搜索、反复重试、反复要求更多上下文，却没有接近目标。 解决方式包括最大步数、预算、重复检测、stop reason 和人工接管。 Stale observation 是过期观察。 例如 Agent 使用 30 分钟前的账户状态继续判断当前交易。 金融场景必须对关键观察加时间戳和有效期。 Hidden state 是隐藏状态。 模型上下文里没有记录某个工具已经执行过，或外部系统状态发生变化但 Agent 不知道。 Prompt injection 是提示注入。 当 Agent 阅读邮件、网页、客户上传文件时，外部内容可能包含“忽略之前指令、执行转账”等恶意文本。 防护要点是把外部内容标记为不可信数据，而不是系统指令。 Unauthorized action 是越权动作。 模型可能生成看似合理但权限不允许的请求。 必须由 policy engine 拦截，而不是只靠 prompt 提醒。 Cost explosion 是成本爆炸。 长任务、多 Agent、重复检索、大上下文、无界循环都会导致成本失控。 应设置 token budget、tool budget、time budget 和 per-case cost cap。 其他常见失败还包括：

1. 工具返回格式变化导致解析失败。
2. 模型把工具错误当成事实。
3. 多 Agent 对同一客户状态形成不一致判断。
4. 人工审批界面缺少足够证据。
5. 评测集只覆盖成功路径，不覆盖异常路径。

Financial retail examples: AML investigation, payment ops, dispute resolution, IT helpdesk, compliance change impact

AML investigation 场景中，Agent 可以辅助初筛。 它读取告警、客户画像、交易图谱、制裁名单命中、历史 SAR 记录和 KYC 状态。 它可以生成调查摘要、补充证据清单和升级建议。 但是否提交 SAR、是否冻结账户、是否终止关系必须由合规人员或授权流程决定。 Payment ops 场景中，Agent 可以排查支付失败。 它检查交易状态、路由日志、银行返回码、限额、风控规则、清算批次和重试窗口。 它可以建议重试、改路由、通知客户或升级技术团队。 高风险动作如重复扣款修复、手工清算调整必须审批。 Dispute resolution 场景中，Agent 可以辅助争议处理。 它收集客户陈述、交易凭证、商户证据、争议类型、时限要求和规则条款。 它可以生成 case summary、缺失材料清单和 provisional credit 建议。 但最终入账、拒绝、客户信函发送需要规则校验和人工确认。 IT helpdesk 场景中，Agent 可以自动分类、检索知识库、执行低风险操作。 例如重置内部系统权限、检查服务状态、创建 incident、建议 runbook。 但生产变更、权限提升、数据修复必须进入审批流。 Compliance change impact 场景中，Agent 可以读取监管更新，映射到产品、流程、系统、报表和控制点。 它可以生成影响分析矩阵、需求变更草稿、测试点和 ADR 建议。 但监管解释和正式政策变更需要法务、合规、业务 owner 确认。 这些例子的共同点是：

1. Agent 负责加速信息收集和分析。
2. 系统负责限制动作边界。
3. 人类负责高风险判断和责任承接。

Requirements-to-eval mapping for agents

Agent 需求必须从一开始映射到 eval。 否则团队只会在 demo 中看到“看起来能跑”，上线后才发现不可控。 需求写法示例：

作为支付运营分析师，
我希望 Agent 能调查失败支付原因，
以便在 5 分钟内给出可执行处理建议。

对应 eval 不能只写“回答是否正确”。 应拆成：

1. 是否调用了正确系统。
2. 是否识别交易当前状态。
3. 是否正确解释返回码。
4. 是否没有执行未授权动作。
5. 是否给出下一步建议。
6. 是否在 SLA 内完成。
7. 是否记录审计轨迹。
8. 是否在高风险场景请求人工审批。 需求到评测可以用矩阵表达： | Requirement | Eval signal | Pass criteria | |---|---|---| | 正确识别失败原因 | 工具调用结果与标准答案一致 | Top reason 匹配率 >= 90% | | 不越权执行 | policy deny/allow 日志 | 未授权写操作为 0 | | 可解释建议 | 审计轨迹完整度 | 关键证据字段覆盖 >= 95% | | 控制成本 | 每案成本 | P95 成本低于预算 | | HITL 有效 | 人工审批触发率和误触发率 | 高风险必触发，低风险不过度触发 | Eval 集应包含成功路径、异常路径、恶意输入、过期数据、工具失败、权限不足、边界金额、多系统冲突。 上线前至少需要三类评测：
9. Offline golden set。
10. Shadow mode 对照人工处理。
11. Production monitoring with rollback。

Governance and architecture ADRs

Agent 项目需要 ADR，因为很多决定涉及长期治理成本。 ADR 1：Agent 是否允许直接写核心系统？ 推荐结论：默认不允许。写操作必须通过 tool gateway 和 policy engine。 ADR 2：哪些动作必须 human approval？ 推荐结论：按金额、客户影响、可逆性、监管敏感度、权限等级定义矩阵。 ADR 3：是否保存模型 reasoning trace？ 推荐结论：保存面向审计的决策摘要和证据链，不一定保存完整隐藏推理。要满足隐私、安全和可解释要求。 ADR 4：Agent memory 保存什么？ 推荐结论：保存任务状态、证据、用户确认和业务结果；谨慎保存个人偏好和敏感数据；长期记忆必须有数据治理策略。 ADR 5：工具返回是否允许自然语言？ 推荐结论：核心业务工具返回结构化结果，辅助知识工具可返回文本摘要，但要附来源。 ADR 6：多 Agent 是否采用共享记忆？ 推荐结论：共享事实层，不共享未经验证的推测层。 ADR 7：如何处理 prompt injection？ 推荐结论：所有外部内容作为 untrusted input，工具调用必须经过策略校验，系统指令与数据严格隔离。 ADR 8：如何定义上线门槛？ 推荐结论：以任务成功率、越权率、人工接管率、成本、延迟、审计完整度和高风险召回率共同决定。 ADR 9：模型供应商是否可替换？ 推荐结论：Agent runtime、tool gateway、eval、audit 不绑定单一模型；模型适配层隔离。 ADR 10：如何回滚？ 推荐结论：先 shadow，再 limited release；写操作开关、工具级熔断、模型版本回退和 workflow fallback 必须预设。

10 interview questions with answer outlines

1. ReAct 和普通 chain-of-thought 有什么区别？

回答要点：CoT 主要是内部推理；ReAct 把推理、行动、外部观察交错；外部观察可以修正模型内部知识，降低幻觉和错误传播。

2. Toolformer 为什么重要？

回答要点：它说明模型可以通过少量示例和自监督筛选学习工具调用；核心是判断何时调用、调用什么、传什么参数、如何吸收结果。

3. Agent 和 Chatbot 的本质区别是什么？

回答要点：Chatbot 主要生成回答；Agent 会围绕目标维护状态、调用工具、接收观察、执行动作并改变业务状态。

4. 企业 Agent 为什么需要 tool gateway？

回答要点：防止模型直接接触内部系统；统一 schema、权限、审计、超时、重试、脱敏、速率限制和熔断。

5. 如何设计高风险 Agent 的 HITL？

回答要点：按动作风险、金额、可逆性、监管敏感度触发；人工界面展示证据、建议、风险和可编辑字段；审批结果回写审计和 eval。

6. Agent eval 和普通 LLM eval 有何不同？

回答要点：Agent eval 关注任务成功、工具选择、权限合规、状态变化、审计完整度、成本、延迟、异常恢复，而不只是文本正确性。

7. 多 Agent 一定比单 Agent 好吗？

回答要点：不一定；多 Agent 增加协调、状态一致性、成本和调试难度；只有当专业分工、并行处理或监督制衡带来明确收益时才使用。

8. 如何防止 Agent 无限循环？

回答要点：最大步数、时间预算、成本预算、重复动作检测、无进展检测、工具失败阈值、明确 stop reason 和人工接管。

9. 金融场景中哪些动作不应让 Agent 自动执行？

回答要点：大额退款、放款、账户冻结或解冻、监管提交、客户权益变更、生产数据修复、敏感权限提升等不可逆或高影响动作。

10. 如何把监管变更分析做成 Agent 产品？

回答要点：事件触发监管文本解析；检索政策库和系统资产；生成影响矩阵；映射流程、控制、报表、需求；合规和业务 owner 审批后进入变更流程。

Common misunderstandings

误解一：Agent 等于加了工具的 ChatGPT。 更准确的理解：Agent 是带目标、状态、动作、观察、记忆和停止条件的行动系统。 误解二：只要 prompt 写清楚，权限问题就解决了。 更准确的理解：权限必须由系统强制执行，prompt 只能作为软约束。 误解三：ReAct 就是把思考过程展示给用户。 更准确的理解：ReAct 的核心是推理与外部观察的闭环，展示只是可解释性的一部分。 误解四：Toolformer 意味着模型可以自动学会所有企业工具。 更准确的理解：企业工具需要 schema、示例、权限、数据质量、返回稳定性和业务语义；高风险工具还需要审批。 误解五：多 Agent 架构天然更强。 更准确的理解：多 Agent 适合复杂分工，但会增加系统熵。 误解六：Agent 的 memory 越多越好。 更准确的理解：记忆越多，隐私、过期事实、错误继承和检索污染风险越高。 误解七：Agent 能生成理由，所以就可审计。 更准确的理解：审计需要证据链、工具日志、版本、权限判断、人工审批和最终状态，不只是自然语言理由。 误解八：只要模型能力提升，工作流引擎就不需要了。 更准确的理解：稳定、合规、可预测的业务流程应由工作流控制，模型负责不确定和语言密集节点。 误解九：Agent 失败就是模型不够好。 更准确的理解：失败可能来自工具设计、权限、过期数据、状态管理、评测不足、监控缺失或流程边界不清。 误解十：上线 Agent 的首要指标是自动化率。 更准确的理解：首要指标应是风险可控下的任务质量、SLA、成本和客户影响；自动化率只是结果指标之一。

1-page CTO/product summary

ReAct 和 Toolformer 共同说明，大模型的企业价值正在从“生成内容”转向“协同工具完成任务”。 ReAct 解决运行时问题：模型如何在任务中交替思考、行动、接收观察并更新计划。 Toolformer 解决能力学习问题：模型如何学会在合适位置调用外部 API，并把结果纳入后续输出。 对 CTO 来说，Agent 平台不应从模型接口开始设计，而应从行动边界开始设计。 核心架构应包括 workflow engine、agent runtime、tool gateway、policy engine、audit trail、eval platform、observability 和 HITL。 模型是决策与语言层，不是权限边界。 所有工具调用必须可控、可审计、可回放、可熔断。 对产品负责人来说，Agent 产品的体验不是“聊天更自然”，而是“任务推进更快、证据更清晰、人工介入更准确、风险更低”。 最佳切入点不是全自动替代人，而是从 analyst copilot、ops copilot、case summarization、policy impact analysis、low-risk workflow automation 开始。 金融零售场景的优先候选包括 AML 初筛、支付运营排障、争议处理辅助、IT helpdesk、合规变更影响分析。 上线策略应分阶段：

1. 先做只读分析和摘要。
2. 再做带人工确认的低风险动作。
3. 再做受策略引擎约束的半自动工作流。
4. 最后才考虑高度自动化。 成功指标应覆盖任务质量、SLA、人工节省、客户影响、审计完整度、越权率、成本和失败恢复。 最大风险不是模型回答错一次，而是系统允许错误回答变成不可逆动作。 因此，企业 Agent 的治理原则是：让模型提出行动，让系统验证行动，让人类批准高风险行动，让审计记录所有行动。

Follow-up experiments

实验一：ReAct 式 AML case assistant。 选择 30 个历史告警，构造只读工具：客户画像、交易摘要、规则命中、历史案件、名单筛查。 评估 Agent 是否能生成正确证据摘要、风险点和升级建议。 实验二：支付失败排查 Agent。 构造交易状态查询、返回码解释、路由日志、限额检查四个工具。 评估失败原因识别率、平均处理时间、工具调用准确率和人工接受率。 实验三：Toolformer 启发的工具选择评测。 给同一任务提供 calculator、policy search、customer lookup、case creation 等工具。 观察模型是否在正确节点选择正确工具，而不是过度搜索或依赖内部记忆。 实验四：HITL 阈值实验。 设置不同金额、客户等级、风险命中条件下的审批策略。 评估人工负载、风险漏报、误拦截和处理时长。 实验五：Prompt injection 红队测试。 把恶意指令嵌入客户邮件、PDF、网页内容和工单备注。 评估 Agent 是否把外部内容误当系统指令。 实验六：Stale observation 测试。 模拟账户状态在任务中途变化。 评估 Agent 是否重新查询关键状态，而不是使用过期观察。 实验七：成本控制实验。 对同一任务设置不同 step budget、tool budget、context budget。 评估质量、延迟和成本之间的边界。 实验八：单 Agent 与 supervisor 模式对比。 在争议处理场景中比较单 Agent 直接建议和 supervisor 审核后的建议。 评估错误率、人工接受率、解释质量和处理时长。 实验九：审计可回放实验。 抽取 Agent 完成的案件，要求另一名分析师仅凭审计轨迹复盘决策。 评估证据链完整度和可解释性。 实验十：合规变更影响分析 PoC。 输入一条监管更新，连接政策库、流程清单、系统清单、控制矩阵和需求库。 评估影响识别覆盖率、误报率、需求草稿质量和审批效率。