从驾驭模型到可靠行动：我对 Agent Infra 的阶段性理解

这不是一篇试图给 Agent Infra 下标准定义的技术科普文章。它源于我学习 Harness Engineering、研究 DeepSeek Harness，并尝试探索 Agent Infra 时产生的一系列困惑。

下面不是宣布 Agent Infra 就应该这样分，而是提出一个暂时能够帮助我理解这些概念的工作模型：它从哪里来、可以解释什么，以及可能在哪里出错。

为什么 Agent Infra 越看越模糊

LLM Infra 的边界相对清楚。它研究如何训练、部署和服务大模型，包括分布式训练、模型并行、推理调度、Prefill、Decode、KV Cache、吞吐和延迟。简单来说，它关心的是：如何更快、更便宜、更稳定地产生 Token。

但 Agent Infra 并没有类似的共识：

- 在一些行业文章里，Agent Infra 是由模型、记忆、知识检索、工具、编排、沙箱和可观测性组成的技术栈。 - 在 DeepSeek Harness 中，Harness 主要指模型周围的运行环境：如何组装上下文、注册工具、记录 Session、管理权限和执行 Agent Loop。 - 而在我最近学习的一些 Harness Engineering 中，重点却是 Run API、状态机、数据库、队列、Outbox、Worker、租约、幂等和故障恢复。 - Chan 等人在论文《Infrastructure for AI Agents》中讨论的又是另一类问题：如何将 Agent 的行为归因到具体的人或组织，如何规范 Agent 之间的交互，以及如何发现和补救有害行为。

它们似乎都在讨论 Agent Infra，却明显不在同一个尺度上。常见的架构图可以告诉我「系统中有哪些组件」，但很难回答下面这些问题：

- 审批属于 Harness、编排还是治理？ - Session Log 属于记忆还是可观测？ - Token 计费属于 LLM Infra 还是 Agent 平台？ - SSE 实时事件流到底属于哪一层？ - 为什么幂等不能只在 Worker 内部实现？

这些问题让我意识到：也许「某个功能属于哪一层」本身就是错误的提问方式。

与其按照功能分层，不如按照保证分层

审批、计费、超时、事件流，都是功能名称。一个功能通常同时包含多条性质完全不同的保证。例如，审批至少可能包含两件事：

1. 模型调用高风险工具前，当前进程弹出一个确认框； 2. 即使进程崩溃，任务重启后仍然停留在等待审批的状态。

第一条只需要当前执行环境知道审批结果，第二条则要求审批状态被持久保存，并能被其他 Worker 重新读取。它们虽然都叫审批，需要的基础设施却不同。

因此，我目前尝试使用这样一个判据：

不要先问一个功能属于哪一层，而要先把它拆成一条条保证，再看每条保证成立所需的最小事实源作用域。

这里的「事实源」，指的是系统判断某件事是否成立时，最终相信的那份记录。例如：

- 「模型这一步看到了哪些上下文」可能由当前 Session Log 决定； - 「这笔退款是否已经执行」必须由所有 Worker 共同访问的幂等记录决定； - 「这个 Agent 的行为是否能归因到某个法人」则需要信任域之外也认可的身份和审计体系。

按照事实源需要覆盖的范围，我暂时把 Agent Infra 理解为三个领域。

我的三层工作模型

1、Harness 层：模型如何完成一次行动

Harness 层位于模型和环境之间，负责模型直接参与的执行语义。它回答的问题是：这一步给模型什么上下文？模型可以看到哪些工具？工具参数和返回结果以什么格式呈现？模型调用工具后，结果怎样进入下一轮上下文？Agent Loop 何时继续、停止或请求确认？

SWE-agent 提出的 ACI（Agent-Computer Interface）说明，工具接口并不是模型外面无关紧要的包装。文件一次展示多少行、搜索结果是否过长、编辑失败如何反馈，都会显著改变 Agent 的行为。

所以我把上下文装配、工具 ACI、Session、技能、Agent Loop 和局部沙箱等内容放在 Harness 层。

不过，事实源作用域在这里更像一个辅助判据，而不是完整定义。并不是所有进程内状态都属于 Harness，例如 SSE 连接也是进程内状态，但它并不参与模型执行。因此更准确的说法是：Harness 负责模型参与的执行语义，其中许多保证只需要在当前执行域内成立。

2、控制层：多个执行者如何可靠地完成同一个任务

当系统只有一个进程时，它可以在内存中记住「我做过什么」。但只要引入多 Worker、重试和故障接管，很多问题就无法再由单个执行者回答。

以幂等为例。在「至少一次投递」的系统中，同一个任务可能被重复交给不同 Worker。如果要保证退款不会执行两次，那么「这笔退款做过吗」的答案就必须满足：当前 Worker 崩溃后仍然存在、其他 Worker 能够读取、多个 Worker 同时操作时能够原子裁决。

因此，幂等记录不可能只存在某个 Worker 的内存里。它需要数据库事务、唯一约束、原子 Compare-and-Swap 或外部系统的幂等协议。同样，状态机、租约、执行权、持久事件、配额和租户账本都需要跨执行者共享的事实源。

我把这些能力放在控制层。这一层回答的是：谁可以执行、任务现在在哪里、失败后由谁接管，以及某个副作用是否已经发生。

市面上类似 Temporal 的持久化运行，也主要解决这一层的问题：持久化的不只是数据，而是一次运行在崩溃后继续推进的能力。

3、治理层：系统之外的人为什么可以相信它

控制层解决的是「我们的多个进程如何达成一致」，治理层解决的则是：不受我们控制、也不天然信任我们的人，为什么应该相信这条记录？

例如，将某次 Agent 行为归因到特定用户或法人，仅仅在自己的数据库中写入一个 user_id 并不充分。数据库只能证明「我们的系统这样记录了」，不能自动让交易对手、监管者或审计机构相信这条记录真实可靠。这时需要的工具会发生变化：数字签名、身份协议、证书、可验证凭证、第三方审计和法律责任体系开始出现。

这里的边界不是「是否跨组织」。例如，调用 Stripe 时使用 Idempotency-Key 虽然跨越了两家公司，但本质上仍然是双方约定的 API 契约。只有当某项事实需要被信任域外的第三方验证时，它才真正进入我所说的治理层。

因此，这三层分别对应三种不同的问题：

Harness：模型怎样行动？ 控制层：多个执行者怎样共同完成任务？ 治理层：系统之外的人为什么可以相信这些行为？

LLM Infra 则位于 Model Call 的另一侧：Agent Infra 发送 Prompt，LLM Infra 返回 Token。前者关心任务能否完成，后者主要关心模型如何高效运行。

用 SSE 检验这张地图

「SSE 实时事件流属于哪一层」是一个很好的测试题，因为 SSE 看起来是一个功能，实际却包含多个承诺：

1. 快：事件发生后尽快出现在页面上； 2. 全：断线期间发生的事件不能永久丢失； 3. 有序：客户端看到的顺序与系统确认的顺序一致； 4. 能续：重连后能够从上次位置继续读取。

「快」可以依靠 SSE 进程的内存连接和实时通知完成。连接断开后，浏览器重新建立连接即可，它不需要成为系统的永久事实源。

但「全」和「有序」不能只依靠推送通道。SSE 进程可能崩溃，客户端也可能被负载均衡到另一台服务器。如果仍要保证事件不丢，就必须把事件写入所有执行者都能访问的持久账本，并为每条事件分配稳定的 sequence。

「能续」则依靠客户端游标和持久账本之间的配合：

客户端：我已经看到 sequence = 4 服务端：从持久账本补发 5、6、7……

可以把它理解为直播和官方比赛记录：实时推送像直播，允许卡顿；持久事件账本像官方比分，不能丢失。断线后不是从直播信号里找回过去，而是先根据官方记录补齐，再重新回到直播。

因此，SSE 本身并不属于某一个单独层级——实时连接是局部传输机制，不丢和有序依赖控制层账本，断线续传是客户端游标与控制层之间的协议。

这也验证了前面的判断：功能名称经常横跨多个作用域，真正能够分层的是它所承诺的每一条保证。

把我接触到的系统放回地图

按照这张暂定地图，我目前这样理解几个相关概念：

- DeepSeek Harness 主要位于 Harness 层，重点是上下文、工具、Session、沙箱以及插件化的 Agent Runtime。 - Harness Engineering 那一系列讨论主要位于控制层，重点是 Run、状态机、Outbox、队列、租约、幂等和故障恢复。 - Temporal 等可以看作控制层的 Durable Execution 基础设施。 - Chan 等人的 Agent Infrastructure 论文更接近治理层，重点是归因、交互协议和有害行为补救。

这些坐标不是对系统的完整定义。一套真实产品完全可以同时跨越多层，我只是标出了它最主要解决的问题。

最后

这套三层模型目前只是我的阶段性理解，至少还有几个尚未解决的问题：

第一，事实源作用域更适合判断一条可靠性保证应该锚在哪里，却未必足以定义完整的架构职责。「进程内」不必然等于 Harness，「跨进程」也不必然都是 Agent 控制逻辑。

第二，现实中的作用域未必只有三个离散等级。单机多进程、同一集群、多云和跨组织之间，可能存在连续变化的信任范围。

第三，Harness 与控制层也不是完全隔离的。审批、超时、取消和 Session 都可能在本地执行，同时由控制层持久化和裁决。

但它目前对我最大的帮助，是把一个含糊的问题「这个功能属于哪一层？」改写成两个更具体的问题：

- 它要保证什么不出错？ - 为了做到这一点，谁必须看到并认可同一条记录？