从零开始搭一个企业级 Agent Harness9/10：解决完这些问题后，一个完整的企业 Agent 应该长什么样？

第一章里，退款Agent只有一个很小的循环：模型判断下一步，调用工具，再读取结果。它很快，却不知道什么时候才算完成，也不知道一次超时以后钱到底退了没有。

我们一路补上任务契约、状态、工具边界、恢复、权限、评测和协作。现在把第一章那笔重复扣款对应的订单再送进来，看这些部件怎样在同一个系统里接力。

用户说：“这张订单被扣了两次，请退回多收的42美元。”入口先确认用户和所属企业（租户），再把这句话写成可验收的任务。模型随后提出退款意图。真正的执行，要经过政策、批准、短期凭证、支付系统和最终核验。每一步都留下证据，下一步才知道该相信什么。

前面每一章都处理了一个局部问题；这一章要把它们接起来，回答一次真实请求进来以后，哪个部件先接手、把什么交给下一个部件。

先把职责分成三个部分

图把Harness的职责分成控制、执行和证据三个部分（Control、Execution、Evidence）。它们不是上下级，也不要求部署成三套独立系统；同一个服务可以承担其中几项责任。图里的上下位置只是在整理职责，不表示退款请求要先穿过控制，再穿过执行，最后才到证据。

控制部分（Control Plane）回答：“允许哪个版本，按什么规则做？”这里保存Agent、模型、提示词、工具和skill的版本，管理身份与审批规则，并记录哪个版本已经通过发布检查。执行部分读取这些配置和规则，决定这笔42美元退款可以使用哪个版本、哪些工具，以及何时必须等人批准。

执行部分（Execution Plane）回答：“这笔退款现在走到哪里，下一步做什么？”任务入口先写清完成条件，Harness为模型准备本轮材料；需要等经理批准时，持久运行服务保存进度；批准到达，工具网关把请求送到右侧的支付系统。前面几章做的循环、等待、恢复和工具调用，都在这里接起来。

证据部分（Evidence Plane）回答：“凭什么说这件事做对了？”它从执行开始就采集事件：模型提出了什么动作、谁批准过、工具发出了什么请求。结果核验再查询支付系统，确认42美元确实退回。核验不通过时，它会阻止任务过早完成或触发补查；事故与评测发现系统性问题时，结果还会回到控制部分，让负责发布和事故处置的程序或人员据此停用版本、调整发布规则。

证据部分不是保存所有业务数据的数据库。订单、余额和退款事实仍由订单系统与支付系统负责；这里保存关联编号、授权与调用记录，以及从权威系统取得的核验结果，让我们能把一次任务和真实业务结果对上。

图底部的三个编号把记录接起来：任务编号认出同一件退款请求，运行编号区分每次执行，稳定动作编号认出同一次业务退款。任务可以重新运行，运行编号也可以变化，但原来那笔退款的动作编号要保持不变，支付服务才知道这是恢复旧动作。我们沿着这些编号，才能从客户的一句“钱怎么还没到”，找到当时的批准、调用和支付结果。

控制部分（Control Plane）：管理Agent版本、身份、政策、部署配置和发布门槛，并把有效配置提供给执行部分。

执行部分（Execution Plane）：接收任务、构建上下文、调用模型与工具，并保存执行进度。

证据部分（Evidence Plane）：采集执行事件，关联任务依据、授权和外部效果，并支持结果核验、评测与事故追查。

一笔退款怎样让这些部件协同

接下来，我带大家沿着同一笔退款走一遍。每一步先看眼前的问题，再看控制、执行和证据三个部分分别做什么。

图里的八个编号是退款的业务顺序：接收请求、准备材料、提出动作、检查权限、带凭证经过工具网关执行、支付后端授权去重、查询支付结果、带证据完成。控制规则、执行状态和证据记录从头到尾都在配合，并不是走完执行以后才开始收集证据。

第一步：先把一句话变成可验收的任务

用户说“退回多收的42美元”，信息还不够。系统还要确认退的是哪张订单，以及怎样证明这次请求已经处理好。执行部分先确认用户与所属企业，再锁定具体订单、金额、风险和完成条件。这样，“帮我看看”与“执行退款”就不会被当成同一个任务。

控制部分已经发布了当前允许使用的Agent版本和任务规则，但它不负责转发每一次请求。请求直接进入执行部分，同时获得任务编号和运行编号；证据部分从这里开始记录原始请求与使用的版本。

第二步：只准备这次退款需要的材料

执行部分按照控制规则，只取这张订单的已验证事实、当前进度和少量最近事件。长期记忆或旧对话先经过权限与相关性检查，再进入模型。这样既不会把别人的订单带进来，也不会用一大段无关历史淹没本轮问题。

证据部分同时记下用了哪些事实和规则版本。以后结果出错，我们才能分清是材料不对、规则不对，还是后面的执行出了问题。

第三步：模型只能提出退款动作

模型读完材料，可以提出“给这张订单退42美元”，但不能直接调用支付接口。执行部分为这个提议分配稳定动作编号；即使任务重启，同一笔退款仍使用同一个编号，不会重新生成另一个动作。

提议的订单、金额和理由也写入证据。后面的政策检查、人工批准与支付结果，都要和这份原始提议对得上。

第四步：先检查权限，需要时等人批准

控制部分保存“什么金额需要批准、谁可以批准、哪些工具可以使用”这些规则。执行部分拿这笔具体退款逐项检查；需要经理批准时，它保存当前进度并暂停，不占着一个进程空等。

批准到达以后，系统记录批准人、时间和动作摘要。这份摘要是对订单、金额和动作按统一格式计算出的内容指纹，用来检查批准的内容与即将执行的内容是否一致。如果批准的是另一张订单或另一个金额，工具网关会拒绝继续。这里的分工很清楚：规则由控制部分配置，等待与检查由执行部分完成，批准记录成为证据。

第五步：带着限时凭证安全执行

获准以后，凭证服务根据控制部分设定的范围与有效期，签发一份短期凭证。它只允许对这张订单执行这一个退款动作，过期后不能继续使用。长期主密钥不进入模型上下文，也不留在隔离环境里。

工具网关先检查政策和凭证，再把带稳定动作编号与幂等键的请求交给支付服务。执行部分保存已经生成的意图、批准结果和等待条件；凭证签发、网关检查与工具调用则沿途进入证据记录。

第六步：支付后端再次授权并去重

工具网关允许调用以后，支付服务仍会用自己掌握的订单归属做最后授权，并用幂等键认出同一次退款。幂等键随原动作保持不变，支付服务把它与处理结果一起保存；再次收到同一笔请求时，就能返回已有结果，避免再退一次钱。这样，前面的Agent和网关即使判断错误，支付后端仍能拒绝不属于当前用户的订单，也不会把同一个请求执行两次。

第七步：接口超时，先查结果

支付接口超时，只能说明这次调用没有及时收到回执，不能说明退款失败。执行部分把状态记为“结果未知”，稍后恢复任务，用原请求编号查询支付系统，而不是再生成一笔退款。

第八步：核验以后，带着证据完成

核验程序要对上三件事：用户要求退42美元；批准、凭证和工具调用针对同一个动作；支付系统里确实出现与这张订单及金额相符的唯一退款编号，而且退款状态已经达到任务契约要求，不能只停在“处理中”。全部对上，任务才能完成。少一项，证据部分就阻止过早完成并让执行部分补查；如果发现重复退款等系统性问题，事故与评测结果还会反馈给控制部分，触发版本停用或发布规则调整。

每项责任都要有人负责

架构画完以后，我按职责把这笔退款交给负责人。

产品团队定义什么叫退款完成；支付团队维护权威结果和幂等规则；安全团队维护工具政策与审批门槛；身份团队签发和撤销凭证；平台团队运行Harness、持久状态和取消通道；质量团队维护评测集与发布门。事故发生时，工具网关的负责人阻断调用，运行服务的负责人取消在途任务，版本管理的负责人停用或回滚Agent。

这份分工还能暴露缺口。工作流引擎保存了进度，却没人查询支付系统，未知结果就永远悬着；工具网关执行了前置政策，却没人让支付系统核对当前用户能否操作这张具体订单，订单边界就不完整；过程记录收得很全，却没人定义完成条件，Agent仍然会过早宣布成功。

最小部署不要求十几套产品。它要求每项责任都有明确负责人：任务契约、持久状态、工具授权、外部动作去重、结果核验、证据保留和事故处置。

2026年的进展：这些运行责任开始有清楚的产品边界

前面这些部件，在2026年的产品里已经能找到越来越清楚的对应位置。看产品发布时，我会把它放回这张图：它替我们保存哪段进度，执行哪项规则，接走哪一块工作？

Anthropic在2026年4月8日公开Managed Agents架构，把运行历史、执行循环和代码隔离环境拆开。运行历史存放在session，也就是保存这段运行历史的会话里，发生一件事就追加一条记录。执行循环由harness运行，代码则放进隔离环境。这样，执行程序重启以后可以根据保留的历史接着做；更换代码执行环境，也不必丢掉整次任务的记录。

Google在2026年4月22日发布Gemini Enterprise Agent Platform，把运行Agent、保存记忆、识别身份、检查工具权限，以及观测和评测接到同一平台。对我们的退款任务，价值在于这些基础能力可以一起接入：运行中发生的调用能连到观测记录，工具入口能连到身份政策。企业再把订单授权、退款去重和支付结果核验接到自己的支付系统。

Microsoft Agent Framework 1.0在2026年4月2日正式可用，让.NET与Python应用用代码组织Agent步骤。随后，Agent Framework Harness于2026年7月22日发布，提供可以定制的执行循环，把保存历史、压缩过长上下文、等待批准和记录调用过程接起来。如果我希望逐步调整退款Agent每轮怎么运行，这条路线提供的是可以修改的程序部件。

Amazon Bedrock AgentCore Harness在2026年6月17日正式可用，让团队通过配置接好运行环境、记忆、工具网关、身份和观测，同时保留导出Strands代码的路径。团队先配置运行所需的能力，后续需要更细调整时再进入代码。

OpenAI Agents API在2026年9月10日进入公开测试，把执行循环和云端任务记录做成托管服务。采用这条路线，应用提交任务并接入企业工具，由平台运行循环、维护会话；企业把退款入口和结果核验接在自己的系统一侧。

这些产品接管的范围不同。选型时我按三个部分逐项标出：谁管理版本和规则，谁运行循环并保存状态，谁隔离代码，谁签发凭证，谁控制工具，谁核验支付结果，谁保留跨部分证据。

再看三个部分怎样闭环

现在回看这笔42美元退款，三个部分的关系已经清楚了。控制部分提前发布可用版本、工具和政策；执行部分接住请求，准备材料、等待批准、调用工具并保存进度；证据部分从任务入口开始，把提议、批准、调用和支付结果连起来。它们分工合作，不是三道必须依次穿过的关卡。

执行过程中，证据核验可以阻止任务过早完成，也可以要求执行部分补查。发现重复退款等系统性问题以后，事故与评测结果再回到控制部分，触发版本停用或发布规则调整。这样，控制给出规则，执行完成工作，证据校验结果并把问题反馈回去，形成一个闭环。

第一章那个脆弱的循环没有消失。它仍然负责判断下一步，只是被一套能保存、约束、验证和解释它的系统包围起来。

最后还剩一个现实问题：这套系统里，哪些部分值得自己写，哪些可以直接交给现成框架和产品API？下一篇用同一笔退款比较四条路线。