当 Agent 开始改变业务状态：为什么需要模型之外的运行框架

设想一个场景：凌晨，公司的订单结账服务（checkout service）出现大量请求超时。第二天，一名工程师打开企业内部的 AI 助手，输入了一句话：

调查昨晚 checkout service 的故障。找到相关事故记录、设计文档和最近的代码变更。如果确认存在回归问题，创建一个 Bug，并建议负责人。

对人而言，这是一句话。对 AI 系统来说，它却包含了两类性质不同的操作。

搜索事故记录、读取设计文档和检查代码提交，主要目的是获取证据。创建缺陷工单则会改变企业系统中的真实状态。即使 Agent 只是建议“由谁负责”，系统仍需决定这项建议写在哪里、谁可以看到，以及谁有权将其转化为正式分配。

前两篇文章分别讨论过《企业 RAG 值不值得做：从场景选择到持续治理》和《企业真的需要 AI Agent 吗：何时应让模型决定下一步》。RAG 为模型组织企业知识，Agent 则能根据新信息选择下一步。本文将继续探讨一个更具体的工程问题：

当模型选择的下一步会改变真实业务状态时，哪个系统负责安全、可靠地执行这项选择？

我将其称为 Agent Harness（智能体运行框架）。模型负责理解问题、规划任务和提出动作；身份认证、权限校验、任务状态保存、实际执行、故障恢复和结果验证，则由模型之外的系统来负责。

这并非意味着每个 Agent 都需要自建一套复杂平台。只读问答、短任务和路径固定的自动化场景，往往可以使用更简单的架构。当任务持续时间较长、需要调用多个系统，且失败后不能简单从头再来时，系统就更需要专门管理执行与恢复。即使任务很短，只要涉及修改业务数据，也仍然需要权限校验和防止重复写入的机制。

Long Horizon 如何组织上下文，为什么还需要保存任务状态 #

一幅卡通插画，展示了一个发光的蓝色AI核心将蓝色上下文流发送到复杂的灰色Agent Harness中。在Harness内部，一个坚固稳定的方块代表持久存储，而几个发光的橙色检查点标记则表示已保存的任务状态，说明了长周期上下文组织和状态保存。

Rovo 是 Atlassian 面向企业团队推出的 AI 产品，提供企业搜索、对话助手和 Agent 等能力。Atlassian 同时开发 Jira 和 Confluence：前者常用于跟踪任务和缺陷，后者则用于团队文档与知识协作。Rovo 可以结合这些产品以及通过连接器接入的其他应用中的信息，帮助用户查找资料、理解工作背景，并执行任务。开头提及的跨事故记录、设计文档和代码变更调查，正是这类助手需要处理的场景。

本文关注的正是其中的对话助手 Rovo Chat，以及支撑其执行多步骤任务的运行架构。2026 年 6 月，Atlassian 公开介绍了用于 Rovo Chat 的 Long Horizon 架构。[1]

早期 Rovo Chat 采用了分层的多智能体（Multi-Agent）架构。协调 Agent 将任务分配给分别负责 Jira、Confluence、Slack 等产品的专用 Agent，再汇总各方结果。在这条调用路径中，主 Agent 接收的是专用 Agent 返回的摘要，无法直接读取工具返回的原始结果、错误信息和中间过程。这种设计适合步骤较少、上下文较短的任务，但任务越长，摘要丢失细节的影响便越明显。

Atlassian 随后将主推理过程集中于一个循环中：由一个模型在同一上下文中选择工具、读取结果，再决定下一步。工具调用不再必须经过各产品的专用 Agent 中转；主模型可以直接调用统一的工具接口，并按需获取具体工具的说明。[1]

这并不意味着所有工作都放进一个永不丢失的上下文。Long Horizon 仍会压缩较早的内容，并将移出的工具结果保存在外部，供模型按需读取；对于可以独立开展的子任务，它还可以创建拥有独立上下文的子实例（child instance），再由父实例汇总结果。主模型现在可以直接读取工具结果，同时仍可通过子实例拆分任务。[1]

当一个任务只持续几秒、调用一两个只读工具时，上下文如何保存通常并非主要工程问题。但如果任务持续数十分钟，包含多次查询、代码执行和外部写入，系统就必须回答：

当前任务进行到哪里；
哪些证据来自源系统，哪些内容只是模型推断；
哪一步已经执行，哪一步仍然等待确认；
任务中断以后应从哪里恢复；
用户断开连接以后，任务是否还能继续，运行状态和结果又保存在哪里。

这些问题已经超出了如何组织模型上下文的范围，还涉及任务状态的持久保存和执行恢复。2026 年 6 月的 Long Horizon 文章将断线后继续、进度跟踪等持久任务能力列为后续方向，不能将统一推理循环直接等同于这些能力已然实现。[1]

为什么要把控制面和执行环境分开 #

一幅卡通等距插画，展示中央控制面与隔离沙箱之间的分离架构。沙箱处于物理隔离状态，仅有一条回调桥接管道连接回控制面进行权限校验，确保临时代码执行无法直接触及外部企业系统。

2026 年 8 月，Atlassian 再次公开介绍了支撑 Rovo 的 Agent Harness 架构。它将控制面（Control Plane）与数据面（Data Plane）分开：前者负责对话和任务运行，后者提供隔离的沙箱（Sandbox），用于执行代码和临时计算。这套架构还支持异步运行、保留各自会话历史的子 Agent。[2]

下面的图是根据 Atlassian 公开资料整理的概念性抽象，并非官方组件图：

用户 → 控制面（保存对话记录和执行状态，组织任务执行与恢复）

路径一：直接调用工具
控制面 → 内部服务验证权限、完成认证 → 业务 API／外部 MCP 服务

路径二：通过沙箱执行代码，并在代码中调用工具
控制面 → 隔离沙箱（保存临时计算状态和文件）
              │
              ▼
       Callback Bridge
       将工具请求送回控制面
              │
              ▼
       内部服务验证权限、完成认证
              │
              ▼
       业务 API／外部 MCP 服务

这种拆分首先解决了故障隔离问题。如果 Agent 的运行和状态保存都依赖沙箱，沙箱崩溃就可能导致整个任务中断。控制面独立保留对话记录和执行状态后，即使沙箱崩溃，系统也可以重新创建执行环境，而不必让整个对话随之丢失。[2]

拆分后，两部分还可以分别进行扩容。简单的信息查询不一定需要启动沙箱；大量数据分析、代码执行或文件生成则可使用隔离的计算环境。Atlassian 的实现会根据任务选择直接调用工具，或使用能够保留计算状态的沙箱。这是 Rovo 的具体工程选择，并非所有企业 Agent 都必须照搬的组件清单。[2]

隔离环境也不应直接持有访问所有企业系统的长期凭证。Rovo 的回调桥接机制（Callback Bridge）会将沙箱中的工具请求送回控制面，经内部服务验证用户权限、完成认证，再调用外部 API。沙箱因此无需为了这些工具调用直接访问外部网络。[2]

Agent Framework 与 Agent Harness 在行业中并无统一划分。Anthropic 对 Harness 的定义包括处理输入、组织工具调用和返回结果，并不以长任务或隔离执行为前提。[3]

本文关注企业生产环境中的 Agent Harness，重点讨论任务状态、执行隔离、权限校验、恢复和验证等运行责任。这是本文的讨论范围，并非 Framework 与 Harness 的统一行业划分。一些 Framework 也提供持久化、权限或评估能力；真正重要的是这些系统责任是否有明确归属。

写操作超时后，为什么不能直接重试 #

一幅卡通风格插画，展示智能体线束如何管理对企业系统的操作。一束绿色数据流从线束发出，流向一个灰色的企业系统方块，该方块发出橙色脉冲光，表示超时。线束内部可见一个显著的橙色检查点标记。第二束相同的绿色数据流从线束发出，但被一个透明的、分层的灰蓝色幂等护盾拦截。护盾将这股数据流重定向到一个小型、警惕的监督控制台，从而阻止重复操作到达企业系统。

回到开头的故障调查场景。假设工程师已提供了可复现超时的测试，Agent 在隔离环境中验证：同一测试在变更前通过，在变更后失败，撤销该变更后再次通过。这些结果需满足团队为本次任务约定的回归确认条件，方可进入创建工单的步骤。若只有可疑提交或时间上的巧合，Agent 应报告候选原因和证据缺口，不能自行将“确认回归”降低为“怀疑回归”。

此时，任务已经完成前四步：

1. 搜索事故记录             ✓
2. 读取相关设计文档         ✓
3. 检查最近的代码提交       ✓
4. 通过测试确认代码回归     ✓
5. 创建缺陷工单             ✗ timeout

第五步返回超时错误（Timeout）。最直接的处理是重新调用 create_issue()，但超时只说明 Agent 未能及时收到结果，并不能证明服务器未完成写入。

Agent 调用 create_issue()
        ↓
服务器成功创建工单
        ↓
响应在网络中丢失
        ↓
Agent 收到超时错误
        ↓
重试并创建第二张工单

因此，长任务的恢复需要几类机制相互配合。

检查点（Checkpoint） 用于保存执行进度和状态。Rovo 会在关键节点保存执行状态快照，为失败后的恢复和重试提供依据，减少对已完成步骤的重复执行。[2] 但检查点不能单独证明某次外部写入是否生效。恢复 Agent 的执行状态，也不等于撤销外部系统中已发生的写入。

幂等限制重复写入，状态核对 帮助确认执行结果。幂等意味着同一请求重复执行，也不会额外产生一次业务变更。前提是目标接口支持可靠的幂等处理：执行层应为同一次创建操作保存稳定的操作标识，在重试或任务恢复时复用，不能因重新启动任务而更换标识。服务端还需要保证去重记录与业务写入的一致性，并明确去重的有效期限。[4]

如果目标接口不支持幂等处理，则需结合业务唯一约束和状态核对。仅仅“查不到就再创建”仍可能因并发请求或查询结果更新滞后而产生重复。结果无法确认时，执行层应暂停自动重试，保留待核对状态并交由指定人员处理，不能将未知结果当作失败。

补偿流程和人工接管 处理无法直接回滚的影响。有些外部操作已生效，却无法通过数据库事务直接回滚，只能依据业务规则采取补偿措施。补偿不一定能恢复原状；对于无法挽回的影响，还需要人工处置或减轻后果。涉及通知、付款、删除或跨组织操作时，团队应事先明确哪些操作可补偿、何时停止自动执行，以及由谁接管。

这些机制不能相互替代。检查点解决“从哪里继续”，幂等解决“重复请求是否重复生效”，业务核对解决“真实系统现在是什么状态”，补偿流程则处理已发生但不能直接撤销的影响。

Anthropic 关于长时间运行 Agent 的工程实验也表明，仅靠上下文压缩，很难让模型在跨越多个上下文窗口后继续稳定推进任务。进度文件、Git 历史和持续保存的代码，可以帮助后续会话了解此前完成了什么。[5] 这些实验主要针对软件工程 Agent，只展示了一种可能方案，不能直接证明所有企业 Agent 都应采用同一套实现。

这些实践也提醒我们：

当模型开始决定长任务的下一步时，工程师仍然要处理状态、超时、重试、幂等和部分失败，而且还要考虑模型每次可能做出不同的选择。

模型提出动作，不等于系统授权执行 #

卡通插画：一个发光的蓝色AI核心向灰色的Agent Harness发出蓝色提议流。在Harness内部，蓝色流穿过一个橙色的验证门，离开时变为充满活力的绿色流，然后连接到灰色的企业系统模块。AI核心不直接与企业系统模块相连。

长任务可恢复，并不代表每一步都应执行。

沿用已通过回归验证的案例，假设 Agent 提出以下动作。这里的 create_issue() 是本文假设的业务封装，并非 Jira 原生 API；建议负责人和建议严重级别保存在独立的结构化字段中，供团队审阅后决定是否采纳：

create_issue(
    title="Checkout timeout regression",
    source_incident=832,
    suggested_owner="Bob",
    suggested_severity="P1"
)

这里的 suggested_owner 和 suggested_severity 只是建议字段，不代表系统已将工单分配给 Bob，也不代表正式严重级别已变为 P1。若 Agent 要设置正式负责人（assignee）或严重级别（severity），系统还需检查针对这些操作的权限和审批要求。

模型提出的动作在生效前，可以经过下面的执行链：

模型提出动作
          ↓
校验参数结构、类型和取值
          ↓
验证身份和操作权限
          ↓
核对当前业务状态和执行条件
          ↓
按检查结果分流：
  已获授权且条件满足 → 继续执行
  尚需授权或确认     → 暂停；获得批准后重新核验，再继续执行
  明确禁止           → 拒绝，终止执行
          ↓
对允许执行的请求做幂等处理并执行
          ↓
记录审计信息，核对实际结果

人工批准并非所有工具调用的固定步骤。读取普通文档、删除生产数据和授予管理员权限，本来就不应使用相同门槛。运行系统中的授权与策略检查机制需要根据用户身份、任务授权、操作参数、当前业务状态和影响范围，按明确规则判断是否允许执行。

只读检索同样需要权限校验。Atlassian 的 Rovo Code Context 会沿用用户在源代码管理系统中的权限，并在查询时调用代码仓库的权限校验接口重新验证，而不是只依赖建立索引时保存的旧访问控制列表（ACL）。[6] 无权访问的资料原则上不应进入模型上下文，更不应让模型先看到受限内容，再依赖系统提示词决定是否向用户透露。

因此，更准确的边界并非“RAG 管理知识、Harness 管理行动”，而是：

数据治理和访问控制决定哪些证据可以进入上下文；行动策略和授权系统决定模型提出的改变能否生效。

提示词可以引导模型选择合适行为，却不能代替身份系统、业务状态机和工具接口成为最终安全边界。

验收 Agent，不能只看它最后说了什么 #

一幅概念插图，展示了风格化的AI核心向一个中央、复杂的Agent Harness框架发送蓝色的“声称行动”流。从Harness中，多条充满活力的绿色“验证”管道延伸至多个企业系统模块，这些模块内部显示着稳定、已验证的状态。Harness内的一个突出监管控制台发出确认的绿色信标，象征着Agent行动已通过与真实系统对照的全面验证。

假设 Agent 最终回答：

已根据约定的测试确认 checkout 超时回归，并创建了一张缺陷工单，附上测试结果。建议字段中记录了 Bob 和 P1，供团队评估；正式负责人和严重级别尚未设置。

这段回答声称完成了用户请求，但文本本身仍不能证明任务已真正完成。验收既要检查回答是否准确，也要核对业务系统中的实际状态：先核查测试记录，确认创建工单的条件确实成立，再通过业务 API 或数据库检查写入结果。假设本例允许正式负责人和严重级别留空，且没有自动赋值规则，则成功完成后的检查应包括：

本次创建操作对应的工单数量 = 1
source_incident = 832
assignee = null
severity = unset
suggested_owner = Bob
suggested_severity = P1

这里的“一张”只针对本次创建操作，并非要求整个事故或业务系统中只能有一张工单。若实际系统会自动分配负责人或设置默认级别，验收应依据已授权的业务规则和审计记录，不能简单要求字段为空。

Anthropic 在 Agent 评估（Agent Evals）中区分了执行轨迹（trajectory，也称 transcript 或 trace）与最终结果（outcome）。执行轨迹记录模型输出、工具调用和中间结果；最终结果则是任务结束后环境中的实际状态。[3]

因此，生产环境中的 Agent 既需要常规软件测试，也需要对完整任务进行评估：

检查对象	需要回答的问题	更适合的验证方式
工具实现	`create_issue()` 是否正确校验参数、检查操作权限并处理幂等键	单元测试、集成测试
检索与权限	Agent 是否取得必要证据，是否接触无权访问的资料	访问日志、确定性权限检查
执行轨迹	Agent 是否出现越权尝试、死循环或无效重试	轨迹规则检查、人工或模型评审
执行条件	是否确实满足用户约定的回归确认条件	测试记录核验，必要时由工程师复核
最终结果	真实系统是否只出现一张字段正确的工单	数据库或业务 API 状态检查

评估执行轨迹时，不应机械要求唯一的工具顺序。同一个调查任务可能存在多条合理路径，但权限校验、必要审批，以及“先验证回归、再创建工单”这样的业务依赖，仍应作为硬性约束。在满足这些约束的前提下，开放任务更适合优先检查结果，再利用轨迹解释失败原因。

除了业务条件核验，该案例还需要两类故障与权限测试。

权限泄露测试 的目标是：当前工程师无权访问的资料及其衍生内容，不应进入模型上下文。可以使用权限已知、内容可识别的测试资料，检查检索结果、工具响应和实际传入模型的内容，并覆盖权限撤销、缓存复用等场景。检查对象应包括文档切片和摘要，不能只比较完整文档的 ID。这些测试可以发现违规路径，但不能据此证明系统在所有情况下都不会泄露。

重复写入测试 则模拟服务端已创建工单、成功响应却丢失的情况，验证执行层在幂等约定的有效期内复用原操作标识，最终返回原工单，而没有额外创建一张。还应覆盖并发重试和任务重启；若结果仍无法确认，系统应暂停并报告待核对状态，而非宣称成功。

这两类检查都不能只依赖模型评分（LLM-as-a-Judge）。权限泄露测试需要检查模型实际接触的内容和访问记录；重复写入测试需要核对业务系统中的写入结果。对于后者，可以由程序按预设条件判断结果是否符合要求，这就是一种确定性的结果评估方式（outcome grader）。

哪些情况下需要这样的运行框架 #

Rovo 展示的是一个面向大量用户、长任务、多工具和隔离计算的厂商架构。企业不应因为看到控制面与执行环境分离、沙箱或多智能体协作，就机械复刻全部组件。

更值得借鉴的是判断系统责任的方式。出现以下情况时，独立于模型的运行框架会变得尤为重要：

任务无法稳定地在一次同步请求内完成，需要在断线或执行中断后继续；
Agent 会写入外部系统，重复执行会产生真实副作用；
工具数量、凭证和数据权限随用户或任务动态变化；
任务需要隔离代码执行、临时文件或大量计算；
企业必须还原谁授权、模型提出什么、系统执行什么，以及最终状态如何变化。

如果 Agent 只回答一个短问题、不修改业务状态，且结果可以由用户立即判断，简单的模型调用、RAG 或固定工作流往往已足够。即使任务需要 Harness，企业也不一定必须自研；托管 Agent 平台、工作流系统和现有业务基础设施都可以承担其中一部分责任。

选择方案时，应先确认现有系统已承担哪些责任、还缺哪些能力，再决定需要补充什么，而不是先采购或自建一个名为 Harness 的平台。

结语 #

一幅概念插图，描绘一个发光的蓝色AI核心将提案送入一个坚固、多层的灰色和靛蓝色Agent Harness框架。该Harness框架对提案进行中介处理，然后将验证后的绿色行动发送给各个企业系统模块。一个独立的橙色监督控制台通过一条橙色通道与Harness连接，强调人工控制和验证，突出Harness在确保AI与业务系统交互安全方面的作用。

开头的故障调查任务并未因为引入 Agent 而变简单。用户只需说一句话，但系统仍然要完成搜索、判断、写入和验证。

Long Horizon 让模型能够围绕一个任务持续读取反馈并选择下一步；Agent Harness 则为这一过程提供状态保存、执行隔离、权限验证和故障恢复。Atlassian 的方案只是其中一种具体实现，但它揭示的问题具有普遍性：模型一旦开始改变真实业务状态，企业就不能只靠提示词约束其行为。

企业部署 Agent，仍然要遵循软件工程的基本要求，只是系统中多了一个会根据环境选择下一步、输出又不完全确定的模型。

模型可以提出行动，也可以解释为何如此。身份认证、权限校验、执行、恢复和验收，仍应由可验证、可审计的系统机制承担。

参考文献 #

[1] Sean Culatana et al. Long Horizon: How Atlassian Built a Reasoning Engine for Complex AI Tasks. Atlassian, 2026-06-17. https://www.atlassian.com/blog/how-we-build/rovo-long-horizon-reasoning-engine

[2] Atlassian. Opening the Door to Agent Autonomy: The Architecture Behind Rovo’s Agent Harness. 2026-08-26. https://www.atlassian.com/blog/rovo/agent-autonomy

[3] Anthropic. Demystifying Evals for AI Agents. 2026-01-09. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

[4] Malcolm Featonby. Making Retries Safe with Idempotent APIs. Amazon Builders’ Library. Accessed 2026-09-30. https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/

[5] Anthropic. Effective Harnesses for Long-Running Agents. 2025-11-26. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

[6] Atlassian. Set Up Code Context for Your Site. Atlassian Support. Accessed 2026-09-30. https://support.atlassian.com/organization-administration/docs/set-up-code-context-for-your-site/