大规模 Agent 系统的 Harness设计
从 tool calling wrapper 到可治理的 agent operating environment。本文讨论 Agent 规模化之后，如何防止模型失控，并让 Runtime、Action、State、Trace、Context、Workflow、UI 和人形成可控协作。
1. 规模化之后，如何防止模型失控
模型失控不一定表现为“模型有了自己的意志”。在工程系统里，它更常见的样子是：模型连续行动，却没有稳定状态边界；工具调用不断发生，却没人能解释哪些动作被接受；多个会话都在推进任务，却没有统一的事实来源。
单个 Agent loop 里，这些问题容易被聊天记录掩盖。系统规模变大后，长任务、多会话、多工具、多 Agent、人工审批、Workflow 和 UI 操作会同时出现。此时要防止失控，不能只靠更长 prompt 或更严格的工具描述，而要回答一组运行时问题：谁能改变状态？哪些事实被系统接受？失败后从哪里恢复？后续 Session 应该读什么？UI 展示的是自然语言解释，还是系统当前状态？
Harness 的第一职责，就是把模型的行动冲动放进可治理边界。模型可以声明意图，可以提出下一步，可以请求工具、委派任务或生成 Workflow；但状态变更、权限校验、执行调度、事件记录和恢复路径要由 Runtime 接管。
2. Harness：可治理的 agent operating environment
常见资料会把 Harness 描述成模型外部的基础设施：orchestration loop、tools、memory、context management、state persistence、guardrails、verification loops、sandbox、observability。这些描述有用，但更像组件清单。
更适合大规模 Agent 系统的定义是：Harness 是一个可治理的 agent operating environment。它不是模型，不是 prompt 模板集合，也不是 tool calling wrapper。它提供的是一套运行环境，让模型会话、工具、工作流、人工决策、长期记忆和 UI 操作都能被同一套 Runtime 状态规则管理。
“可治理”意味着每个动作都有对象、权限、证据、状态和恢复位置。模型生成的内容不是事实，工具跑出的结果也不是事实；只有 Runtime 接受、记录并投影之后，它们才进入系统的操作视图。
3. Runtime：Agent 系统的治理中心
Runtime 不应该只是把模型输出转成工具调用的胶水层。大规模 Agent 系统里，Runtime 是治理中心：它决定哪些请求可以被接受，哪些动作需要 Gate，哪些结果能进入状态，哪些失败需要恢复或升级给人。
具体来说，Runtime 接受结构化 Command、Action 或 adapter operation，完成 schema 校验、权限校验、Gate 判断、Executor 选择、Assignment 创建、Event 追加、Projection 更新、Trace 维护和恢复管理。模型可以提出行动，Runtime 才能让行动发生。
这个边界让系统的控制权保持清楚：模型负责判断、计划、解释和声明；Runtime 负责接受、校验、调度、记录和恢复。长任务和多主体协作能不能持续，主要取决于这条边界是否稳定。
4. 准确地说：Agent 是模板，真正执行任务的是 Session
大规模 Agent 系统里，“Agent”这个词很容易被用得太宽。准确地说，Agent 是模板：它定义 persona、entry、capability、permission profile、模型偏好和运行策略。它描述一个可复用执行角色，但不直接执行任务。
真正执行任务的是 Session，也就是 Runtime 基于 Agent 模板创建出来的 Agent Session。Runtime 把 Assignment、authority、context refs、artifact refs 和 trace refs 绑定给这个 Session，让每次执行都有稳定 session id、session log、状态、权限边界和 trace。
这个区分能避免两类混乱：第一，把模板配置误认为执行权限；第二，把一个长对话当成所有任务共享的上下文容器。模板可以复用，Session 应该绑定具体任务边界。
5. Action 表意，用声明式替代命令式 Tool Call
Tool Call 的默认语气是命令式的：调用哪个工具，传什么参数，马上执行。这个方式适合简单工具循环，但在大规模 Agent 系统里会把模型推到执行控制位上。模型一旦直接决定工具、参数、顺序和副作用，Runtime 就很难治理。
Action 的作用是表意。它描述“我要做什么语义工作”：读哪些资源、产生什么结果、有什么副作用、依赖什么、期望什么返回粒度、建议由哪类 Executor 处理。模型声明 Action，Runtime 再决定是否允许、如何执行、如何记录。
Tool Call 仍然可以作为 carrier，因为当前模型和 provider 都擅长这个机制。但它进入 Runtime 后要被归一化为 Action。这样一来，读文件、委派 review、请求用户批准、启动 workflow 都能走同一条治理链路，而不是散落成不同的命令通道。
6. 系统状态治理：Event Log、Projection、Trace
系统状态治理的第一步，是不要把所有状态混成一团。聊天记录像事实，数据库行像事实，UI 当前显示也像事实，工具输出也像事实。等系统失败时，团队会发现没人知道该相信哪一个。
协议需要把状态拆成不同角色。Event Log 是 Runtime 接受事实的追加式记录。Projection 是由 Event 和状态规则推导出的当前操作视图。Materialized State 是为了查询、展示、调度和恢复而保存的状态形态。Trace 是把 Event、Action、Assignment、executor invocation、Artifact、Gate、Decision 和 error 串起来的证据链。
Event Log 回答“系统接受了什么”。Projection 回答“现在应该怎么操作”。Trace 回答“为什么会走到这里，证据在哪里”。这三类问题都很具体，不能交给一个非结构化 transcript 来承担。
7. Context：不是简单 transcript 回放
Context 不是把 transcript 原样回放给模型。很多 Agent 系统默认把历史消息、工具输出、失败尝试和旧计划塞回上下文。缓存可以降低成本，但不能消除语义噪声。陈旧 trace、长 stdout、被替代的 plan 和无关 child session 摘要仍然会影响模型注意力。
Context 应该由 Runtime 构造。Runtime 根据当前 Assignment 的目标、当前 Projection、Memory scope、Artifact refs、环境信息、约束和可见性策略，生成 Context Bundle。模型看到的是适合当前判断的输入，不是系统历史的堆叠。
Session Log 仍然重要，但它是持久记录，不等于下一次模型调用的输入。当前 Projection 应该优先于历史 Memory，完整输出应该以 Artifact 或 log 保存，模型默认读取摘要和引用。Context 的价值在于选择，而不是堆满。
8. Agent Session 之间不直接通信
多 Agent 的收益来自上下文隔离、并行探索、独立评估和明确交接。但多 Agent 也会带来成本、冲突和状态一致性问题。让 Agent Session 互相转发自然语言消息，看起来直接，实际会把系统带回不可审计的聊天网络。
更稳的方式是：Agent Session 之间不直接通信。Agent A 可以提交结果、Artifact、风险、未决问题或下一步 Action 建议。Runtime 接受这些内容后，生成 Event、更新 Projection、创建 Handoff 或 Assignment，再把结构化 Context Bundle 交给 Agent B。
这样每一次交接都有 contract、authority、evidence、budget、unresolved issues 和 trace continuity。协作不靠自由文本延续，而靠 Runtime 管理的任务边界和证据传递。
9. Workflow：协议支持直接生成 Workflow，又不止于 Workflow
协议应该支持直接生成 Workflow。多阶段、并行、多 Agent、可恢复、需要进度和审计的任务，适合由 Workflow Runner 生成 durable DAG，并通过 Runtime-owned 的 `workflow.create`、`workflow.start`、`workflow.decide` 等入口运行。
但 Harness 不止于 Workflow。Workflow 是基于 Harness 基础 DSL 的 durable orchestration adapter，用来表达一类长任务编排。短生命周期的 action graph、普通 tool action、Agent delegation、human approval、release gate、evaluation loop，也应该落在同一套 Runtime 治理模型里。
这个边界很关键。Workflow 可以定义 DAG、node state、artifact、decision record 和 failure policy，但 Runtime 仍然拥有 validation、state transition、scheduling、permission、event、projection 和 gate。Workflow 描述编排状态，不应该变成绕过 Runtime 的脚本语言。
10. 人的位置：UI 治理操作面，人也是生产环境的一环
大规模 Agent 系统里，人不是站在系统外的观察者。人会批准、暂停、恢复、回答 Decision、处理异常、审查结果、设定偏好，也会承担 owner、reviewer、operator 等生产角色。人的动作同样需要进入治理链路。
UI 是人的治理操作面，而不是聊天记录渲染器。UI 应该读取 Projection、Event、Artifact、Trace、Memory 和 Concept。UI 中所有会改变系统状态的操作，都应该提交为 Runtime Command 或受控 Action。暂停、恢复、重试、取消、回答 Decision、重新验证，都不能只改前端状态。
更进一步，UI projection、Artifact summary 和 Trace export 都应该 agent-readable。它们既给人看，也给后续 Agent Session 读。稳定 id、状态、summary、refs、evidence、actor、time 和 visibility metadata，是把“人”纳入生产环境的基础。
11. 与常见 Harness 理念的不同之处
常见 Harness 理念通常从“让模型能工作”出发：给模型工具、上下文、沙箱、记忆、评测、可观测性和工作流。这些能力都必要，但它们仍然偏向能力拼装。
OpenAI、Anthropic 和 Agent Harness Survey 的资料都指向一个趋势：Agent 可靠性不能只靠模型能力，模型外部的执行环境、上下文、状态、验证、可观测性和治理会显著影响结果。OpenAI 更强调 agent-first 工程组织、SDK primitives、sandbox、manifest、state externalization 和 durable execution。Anthropic 更强调 session / harness / sandbox 解耦、长任务 handoff、planner / generator / evaluator、多 Agent 成本和 trace-based eval。Survey 则把 Harness 分成 Execution、Tooling、Context、Lifecycle、Observability、Verification、Governance 等层。
Open Agent Harness 的不同之处在于，它不把 Harness 写成组件百科，也不把 Workflow 当成全部答案。它把能力收敛到 Runtime 可执行的协议对象：Model 声明，Runtime 治理，Action 表意，Executor 执行，Event 记录，Projection 操作，Trace 举证，Context 构造，Adapter 扩展，UI 操作。
| 常见理解 | 价值 | 本协议的取舍 |
|---|---|---|
| Tool calling wrapper | 让模型能访问外部能力 | Tool Call 是 carrier；Action 才是表意层和治理入口 |
| Agent loop | 实现 plan-act-observe 循环 | loop 被拆成 Runtime 可治理的状态迁移 |
| Workflow engine | 支撑长任务、并行和恢复 | 协议支持生成 Workflow，但 Harness 不止于 Workflow |
| Observability stack | 记录执行路径和失败原因 | Trace 是治理证据层，连接 Event、Action、Artifact 和 Decision |
| UI console | 让用户观察和操作系统 | UI 读取 Projection / Event / Trace，并通过 Command 改变状态 |
12. 结尾：大规模 Agent 协作的关键是可控
大规模 Agent 协作当然需要更强的模型、更好的工具、更长的上下文和更稳定的沙箱。但这些只能扩大能力半径，不能自动带来可控性。系统能不能持续运行，取决于它是否有稳定的治理协议。
可控不是限制模型思考，而是让模型的行动进入协议。模型声明意图，Runtime 判断和执行，Event 记录事实，Projection 提供当前视图，Trace 保留证据，Context 控制输入，Workflow 扩展长任务，UI 承载人的操作。
当 Agent 从一次性对话走向长期运行环境，Harness 就不再是外壳。它变成了 Agent 系统的操作环境，也变成了人、模型、工具和流程之间的治理边界。大规模 Agent 协作的关键，不是放大自主性，而是让自主性可控。