开篇这不是一篇试图给 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 内部实现这些问题让我意识到也许某个功能属于哪一层本身就是错误的提问方式。与其按照功能分层不如按照保证分层审批、计费、超时、事件流都是功能名称。一个功能通常同时包含多条性质完全不同的保证。例如审批至少可能包含两件事模型调用高风险工具前当前进程弹出一个确认框即使进程崩溃任务重启后仍然停留在等待审批的状态。第一条只需要当前执行环境知道审批结果第二条则要求审批状态被持久保存并能被其他 Worker 重新读取。它们虽然都叫审批需要的基础设施却不同。因此我目前尝试使用这样一个判据不要先问一个功能属于哪一层而要先把它拆成一条条保证再看每条保证成立所需的最小事实源作用域。这里的「事实源」指的是系统判断某件事是否成立时最终相信的那份记录。例如“模型这一步看到了哪些上下文”可能由当前 Session Log 决定“这笔退款是否已经执行”必须由所有 Worker 共同访问的幂等记录决定“这个 Agent 的行为是否能归因到某个法人”则需要信任域之外也认可的身份和审计体系。按照事实源需要覆盖的范围我暂时把 Agent Infra 理解为三个领域。我的三层工作模型1、Harness 层模型如何完成一次行动Harness 层位于模型和环境之间负责模型直接参与的执行语义。它回答的问题是这一步给模型什么上下文模型可以看到哪些工具工具参数和返回结果以什么格式呈现模型调用工具后结果怎样进入下一轮上下文Agent Loop 何时继续、停止或请求确认SWE-agent 提出的 ACIAgent-Computer Interface说明工具接口并不是模型外面无关紧要的包装。文件一次展示多少行、搜索结果是否过长、编辑失败如何反馈都会显著改变 Agent 的行为。所以我将上下文装配、工具 ACI、Session、技能、Agent Loop 和局部沙箱等内容放在 Harness 层。不过事实源作用域在这里更像一个辅助判据而不是完整定义。并不是所有进程内状态都属于 Harness例如 SSE 连接也是进程内状态但它并不参与模型执行。因此更准确的说法是Harness 负责模型参与的执行语义其中许多保证只需要在当前执行域内成立。2、控制层多个执行者如何可靠地完成同一个任务当系统只有一个进程时它可以在内存中记住「我做过什么」。但只要引入多 Worker、重试和故障接管很多问题就无法再由单个执行者回答。以幂等为例。在至少一次投递的系统中同一个任务可能被重复交给不同 Worker。如果要保证退款不会执行两次那么“这笔退款做过吗”的答案就必须满足当前 Worker 崩溃后仍然存在其他 Worker 能够读取多个 Worker 同时操作时能够原子裁决。因此幂等记录不可能只存在某个 Worker 的内存里。它需要数据库事务、唯一约束、原子 Compare-and-Swap 或外部系统的幂等协议。同样状态机、租约、执行权、持久事件、配额和租户账本都需要跨执行者共享的事实源。我把这些能力放在控制层。这一层回答的是谁可以执行、任务现在在哪里、失败后由谁接管以及某个副作用是否已经发生。前面的一篇文章Agent Loop 不等于上线Run API 与 “两本账、八张表”主要讨论的是这一层。市面上类似 Temporal 的持久化运行也主要解决这一层的问题持久化的不只是数据而是一次运行在崩溃后继续推进的能力。3、治理层系统之外的人为什么可以相信它控制层解决的是「我们的多个进程如何达成一致」治理层解决的则是不受我们控制、也不天然信任我们的人为什么应该相信这条记录例如将某次 Agent 行为归因到特定用户或法人仅仅在自己的数据库中写入一个 user_id 并不充分。数据库只能证明“我们的系统这样记录了”不能自动让交易对手、监管者或审计机构相信这条记录真实可靠。这时需要的工具会发生变化数字签名、身份协议、证书、可验证凭证、第三方审计和法律责任体系开始出现。这里的边界不是是否跨组织。例如调用 Stripe 时使用 Idempotency-Key 虽然跨越了两家公司但本质上仍然是双方约定的 API 契约。只有当某项事实需要被信任域外的第三方验证时它才真正进入我所说的治理层。因此这三层分别对应三种不同的问题Harness模型怎样行动 控制层多个执行者怎样共同完成任务 治理层系统之外的人为什么可以相信这些行为LLM Infra 则位于 Model Call 的另一侧。Agent Infra 发送 PromptLLM Infra 返回 Token。前者关心任务能否完成后者主要关心模型如何高效运行。用 SSE 检验这张地图“SSE 实时事件流属于哪一层”是一个很好的测试题因为 SSE 看起来是一个功能实际却包含多个承诺快事件发生后尽快出现在页面上全断线期间发生的事件不能永久丢失有序客户端看到的顺序与系统确认的顺序一致能续重连后能够从上次位置继续读取。「快」可以依靠 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 都可能在本地执行同时由控制层持久化和裁决。但它目前对我最大的帮助是把一个含糊的问题这个功能属于哪一层改写成两个更具体的问题它要保证什么不出错为了做到这一点谁必须看到并认可同一条记录