从 Agent Harness 到 Team Harness：让人类与智能体围绕共同工作协作

过去几年，讨论 AI（人工智能）产品时，人们最常问的是：模型有多聪明？它能写多少代码？能否调用工具？能否自主完成任务？

但如果两款产品使用相近的模型，为什么实际体验仍可能完全不同？为什么一个只会给出建议，另一个却能找到项目文件、修改代码、运行测试、操作浏览器、整理文档，并在关键步骤停下来等待确认？

差别往往不只来自模型，而来自模型外面的那套系统：它怎样获得上下文（context），能调用哪些工具，如何执行命令，怎样记住过去，如何接受约束，又如何把一次回答变成可验证、可延续的工作。

这套系统通常被称为 Agent Harness（智能体支撑与约束系统）。

本文中的 Harness 是一个通用技术概念，用来描述模型之外连接上下文、工具、执行与治理的系统，不指向某个特定厂商、产品或同名项目。

而当智能体（Agent）从个人工具走进团队，问题会再次发生变化。个人 Harness 主要解决“一个人怎样更高效地使用一个智能体”；团队真正需要的却是“许多人和许多智能体怎样在同一项工作里共享上下文、分配责任、使用权限、留下证据，并把经验沉淀为下一次可以复用的能力”。

本文把支撑多个人类与智能体围绕持续存在的共同工作共享上下文、承接责任、受控执行并留下可审计结果的一类问题与设计方法，暂称为 Team Harness（团队级人机协作支撑与治理系统）。这是本文采用的工作性定义，不是业界已经形成统一含义的产品品类。

它也不等于多智能体编排（multi-agent orchestration）。多智能体编排关心多个智能体怎样分工、通信和完成任务；Team Harness 关心人类与智能体怎样围绕持续存在的共同工作，保持上下文、责任、权限和审计连续。前者可以成为后者的执行能力，但不能代替后者。

Team Harness 提供的不是更多智能体，而是工作的连续性：换一个人、换一个智能体、跨过一个系统或间隔一段时间，团队仍然知道发生了什么、由谁负责、依据是什么，以及接下来该做什么。

本文尝试从 Agent Harness 出发，分析这类团队级人机协作问题，并进一步讨论：当相关能力进入企业后，Choral 为什么选择用两个相互独立、又彼此连接的产品界面来承载。

什么是 Agent Harness

Harness 原本有“驾驭、连接和约束”的含义。在这里，它指模型之外负责组织上下文、工具、执行环境（execution environment）和安全边界（security boundary）的产品层：模型提供推理能力，Harness 让这种能力进入真实工作。

这不是统一的厂商分类。同类产品也可能自称 AI 助手、编程智能体、副驾驶或智能体平台。判断它是否承担 Harness 角色，可以看它是否在模型之外回答四个问题：模型知道什么、能够做什么、如何持续执行，以及哪些行为受到约束。

因此，很多人其实已经在使用 Harness：

使用方式	常见产品	Harness 在背后做什么
终端（terminal）、集成开发环境（IDE）或桌面中的专业开发	OpenAI Codex、Claude Code、Kimi Code、Lingma IDE	读取代码、修改文件、运行命令与测试，并提供审查（review）和权限边界（permission boundary）。
智能体开发工作台	Cursor、Qoder Desktop、TraeCode、CodeBuddy IDE、Baidu Comate AI IDE	连接代码搜索、终端、差异比较（diff）、规则、Skill（可复用能力）、模型上下文协议（MCP）与任务规划，完成可审查的工程变更。
代码仓库（repository）与云端开发流程	GitHub Copilot cloud agent	在独立环境中研究仓库、修改分支和运行检查，再把结果带回拉取请求（pull request）。
面向普通用户的知识工作	ChatGPT / ChatGPT Work、Kimi	通过自然语言组织文件、网页、应用、数据分析与文档交付。
桌面级通用工作智能体	QoderWork、TraeWork、MiniMax Code、Tencent WorkBuddy	拆解目标并调用 Skill、浏览器、本地文件或专业智能体，交付可验收成果。
企业办公与业务信息	Microsoft 365 Copilot Chat	连接组织知识、办公应用、智能体与管理策略。

这些类别并不互斥。Kimi、Qoder、TRAE、MiniMax 等已经同时覆盖开发与知识工作；专业工具通常显式展示终端、差异比较、权限和执行过程，通用产品则把这些机制隐藏在对话、文件和办公界面之后。Pi、OpenCode 代表更轻量、可组装的一端，强调通过命令行（CLI）、Skill 和扩展（extension）自定义 Harness；Dify、扣子等产品则更接近 Harness 构建平台，用于搭建智能体应用，而不是直接作为一项工作的最终界面。

一套 Harness 的能力通常可以归纳为五组：

上下文与记忆（Context and Memory）：选择当前上下文，并保留值得跨任务复用的信息。
工具与 Skill：连接文件、命令行、浏览器、应用程序接口（API）、MCP 与可复用工作方法。
执行（Execution）：规划、暂停、恢复、并行、重试和验证任务。
治理（Governance）：管理权限、沙箱（Sandbox）、审查、批准（approval）与审计（audit）。
交互界面（Interaction Surface）：通过命令行、编辑器、网页或对话让人参与工作。

因此，智能体的实际能力并不是简单的“模型能力”，而更接近：

智能体的实际能力
= 模型
+ 上下文
+ 工具
+ Skill
+ 执行环境
+ 权限边界
+ 反馈与验证闭环

同一个模型放进不同 Harness，可能表现得像两个完全不同的产品。模型决定推理上限，Harness 决定它能否稳定地进入真实工作。

Harness 不只是工具集合，而是一套工作假设

表面上看，Harness 似乎只是给模型增加了一些工具。实际上，每一种 Harness 都在隐含地回答一组更深的问题：

什么信息值得进入上下文？
什么状态应该被长期保留？
智能体的输出是建议，还是可以直接成为事实？
智能体调用工具时代表谁？
哪些动作可以自动完成，哪些动作必须由人确认？
一次任务完成之后，结果如何进入项目的长期状态？
下一个人或智能体怎样知道前面发生了什么？

例如，一个以个人编程为中心的 Harness，常见的基本结构是：

人类
  ↓
智能体会话（Agent session）
  ↓
代码仓库 / 命令行 / 工具
  ↓
补丁（patch）/ 测试（test）/ 提交（commit）

这套结构非常有效，因为用户、权限拥有者、上下文选择者和最终责任人通常是同一个人。智能体只需要继承这个人的工作环境，再通过沙箱、批准或审查控制风险。

但当它进入团队，这个假设就不成立了。

为什么个人 Harness 不能自然演变为 Team Harness

一个团队里可能同时存在：

多个人类成员；
多种专业角色；
多个通用或专用智能体；
不同权限范围；
多个工作系统；
长时间持续的业务事项；
需要审计和复盘的决定；
需要交接、接受、退回和升级的责任。

这时，仅仅增加多人账号、共享对话或并行智能体，并不会自动得到 Team Harness。

1. 团队需要共享上下文，但不能共享全部对话记录

个人智能体的上下文往往围绕一次会话组织。团队却需要让许多人和智能体共同理解项目状态，同时又不能把所有人的全部对话无限制地塞进每一次推理。

真正有价值的路径应该是：

临时对话
        ↓
事实 / 决策 / 约束 / 证据
        ↓
经审查的共享上下文
        ↓
后续的人类与智能体工作

也就是说，团队上下文不能等同于聊天历史。它必须有范围、来源、时效、权威性和维护责任。一次对话中的推测，与经过确认的规则，不应该以同样的权重进入后续工作。

2. 团队权限不是“智能体继承当前用户权限”这么简单

个人场景里，智能体常常代表正在操作它的用户。团队场景却会立即出现更复杂的问题：

Alice 能否让智能体使用 Bob 才拥有的权限？
智能体是代表某个用户、某个团队，还是以服务身份（service identity）行动？
一个智能体生成的变更由谁负责？
谁可以批准外部发送、付款、发布或生产部署？
智能体看过的敏感信息是否可以出现在另一个范围的输出中？

因此 Team Harness 需要的不只是简单的角色权限，而是身份、委托授权（delegated authority）、作用域凭证（scoped credential）、信息流控制（information-flow control）、审批策略和审计轨迹（audit trail）的组合。

3. 团队协作的核心是责任连续性（responsibility continuity）

对话能传递消息，却不天然表示责任已经转移。一个人说“请你处理一下”，和另一个人明确接受了范围、交付物、截止时间与权限，是两种不同的状态。

团队工作需要显式回答：

谁正在负责？
负责什么范围？
接受了哪些输入？
期待什么输出？
何时算完成？
如果无法完成，交回给谁？

这也是为什么 Team Harness 不能只围绕智能体会话设计。它必须围绕持续存在的工作设计。

从以智能体为中心（Agent-centric）转向以工作为中心（Work-centric）

今天许多智能体产品的基本结构仍然是：

智能体
└── 会话
    └── 任务

它把智能体放在中心，任务是智能体的一次运行。

Team Harness 更适合反过来组织：

此时智能体不再是系统的中心，而是工作中的一种参与者。人类、智能体、外部系统都可以贡献信息、承担责任或产生候选结果，但最终事实必须进入拥有它的业务或知识对象。

这带来一个非常重要的治理原则：

运行时（runtime）准备限定范围的输入。
智能体产出候选结果（candidate output）。
应用校验权限与不变量（invariant）。
归属该事实的产品对象（owning product object）提交持久事实（durable fact）。

智能体的生成结果不应因为“来自智能体”就自动成为事实；运行时也不应因为能够执行，就自动成为业务权威。智能体输出是候选，应用边界（application boundary）负责验证，拥有该事实的对象负责提交。

分析 Team Harness 的五个层面

为了分析 Team Harness 涉及的系统能力，本文把相关问题归纳为五个相互连接的层面。这是一套分析框架，不是所有实现都必须逐项对应的行业标准。

1. 执行层（Execution Plane）

负责让智能体真正完成工作：模型、工具、Skill、命令行、浏览器、运行环境、子智能体（sub-agent）、任务恢复和验证。

这里既需要内部的权限判断与批准，也需要外部的沙箱。前者判断“应该不应该执行”，后者限制“即使判断错了，最多能影响什么”。容器、开发容器（Dev Container）、远程沙箱或受控工作区，都可以成为智能体用完即弃的计算环境（disposable computer）。

2. 上下文层（Context Plane）

负责组织智能体可以使用的上下文：文件、结构化知识、消息、记忆、来源、作用域、版本和有效性。

它的关键不是把更多信息交给智能体，而是把正确的信息、以正确的权威级别、放进正确的工作范围。

3. 协作层（Collaboration Plane）

负责人类与智能体之间的交流、参与关系、提及、讨论、交接与审阅。对话是很自然的起点，但 Team Harness 最终还要表达对话无法稳定承载的责任、状态和业务事实。

4. 治理层（Governance Plane）

负责身份、权限、委托授权、审批、审计、来源、信息披露（information disclosure）和高风险动作边界。它必须避免形成“自动化的隐藏权力通道”。

5. 知识与改进层（Knowledge and Improvement Plane）

负责把一次工作中产生的证据、决定、修正和有效做法转化为长期可复用的知识、Skill、工作流（Workflow）或规则。

这一层让系统不只是在“完成今天的任务”，而是在不断改善团队明天的工作方式。

从 Team Harness 到 Choral 的双产品实现

前面五个层面提供了一种分析 Team Harness 相关能力的方式，但这并不意味着所有能力都必须塞进同一个产品、同一种界面。团队中的工作本来就有不同形态：有些工作需要专业人员直接操作文件、代码和自动化工具；另一些工作则需要更广泛的业务参与者围绕明确事项协作，并获得稳定、易用、可审计的体验。

这形成了一个现实矛盾。专业团队通常追求效率、可编程性和工具自由，不愿意被限定使用某个封闭应用；更广泛的业务参与者则通常更看重易用性、可靠性、明确责任和过程可追溯。如果强行用一个界面同时满足两端，往往不是妨碍专业工作，就是把底层复杂性暴露给不需要理解它的人。

Choral 选择用两个独立但互补的产品回应这个问题：

Choral Forma（以下简称 Forma）：开源的专业知识工程工作空间（professional knowledge engineering workspace），帮助专业团队治理共享上下文。它以文件和 Git（版本控制系统）为基础，让团队保留已有的编辑器、命令行、脚本和智能体工作方式，同时为知识增加结构、引用、检查和审查能力。
Choral Flows（以下简称 Flows）：闭源商业项目，定位为面向业务协作的运行环境（business collaboration runtime），帮助更广泛的业务参与者围绕真实工作与智能体协作。它强调清晰的事项、参与关系、责任、权限、过程记录与结果，让用户不必理解底层文件和工程机制，也能可靠地推进工作。

这里的关系可以直接概括为：Team Harness 是本文用于理解团队级人机协作问题的框架与产品理念；Forma 与 Flows 则是 Choral 回应这一问题的一种双产品实现。

Forma 关注共享上下文怎样被创作和治理；Flows 关注共同工作怎样被组织和运行。任何一方都不是另一方的后台、简化版或附属界面。

这种边界乍看像“专业用户与非专业用户”的划分，更准确地说，它区分的是两种工作模式（work mode）。同一个人可能上午维护规则、写脚本、调整知识结构，处于知识创作与工程模式（authoring / engineering mode）；下午进入一项客户工作，作为审查者（reviewer）或负责人（owner）按既定流程协作，处于业务运行与协作模式（operating / collaboration mode）。

因此可以把两个产品的分工概括为：

知识创作 / 工程模式
          ↓
        Forma

业务运行 / 协作模式
          ↓
        Flows

或者更简洁地说：

Forma = 共享上下文的专业治理与创作界面
Flows = 共同工作的业务运行与协作界面

这两个方向之间既要保持边界，也需要建立知识引用、反馈和责任交接的通道。后文会先分别展开两个产品，再讨论它们怎样跨越边界形成闭环。

Forma：不要挡住专业团队的路

专业团队通常已经拥有自己的工具链：编辑器、Git、轻量标记语言（Markdown）、命令行、脚本、交互式计算笔记本（Notebook）、持续集成（CI）、Agent Harness 和各种自动化。如果企业软件要求他们把一切迁进专有网页界面，专业工作流往往会立刻失去批处理能力、可编程性和智能体兼容性。

Forma 的基本立场恰好相反：

文件仍然是文件。
Git 仍然是 Git。
Markdown 仍然是 Markdown。
命令行和编辑器仍然可用。
智能体可以依据明确结构开展工作。

Forma 在这些基础上增加的是：

由工作空间配置（workspace configuration）定义的配置型内容分组（configured content group，产品界面称为 Space），以及结构定义（Schema）、语义类型（semantic type）、模板（template）与视图（View）；
可解析的引用和关系；
对缺失、冲突、陈旧与不一致上下文的健康诊断（health diagnostics）；
面向人类和智能体的稳定路径与显式结构；
预演（dry run）、差异比较、审查、验证等可审查的操作边界；
在不夺走代码仓库权威地位的前提下，提供网页、命令行与编辑器界面。

这里的 Space 不是 Forma 内置的领域原语（domain primitive），而是配置节点（config node）投影到有效配置（effective configuration）中的内容分组。它所覆盖的路径、结构、创建方式、展示约定和相关视图都来自工作空间配置；“任务”“笔记”“成员”等名称也只是团队可以配置出的领域概念，不是 Forma 预设的对象。

因此，Forma 不是“又一个 Markdown 编辑器”，也不是把知识搬进隐藏数据库的软件即服务（SaaS）。它更像一个基于代码仓库的知识工程工作空间：把普通文件组织成可阅读、可验证、可引用、可维护的共享上下文。

它的产品原则可以概括为：

治理上下文，但尽量不控制专业人员使用什么工具。

Flows：围绕真实工作组织人类与智能体协作

业务协作的起点不同。大多数参与者不应该被要求理解文档元数据（frontmatter）、结构定义、Git 差异、文件路径或知识图谱（knowledge graph）维护。他们更关心的是：现在发生了什么、谁在处理、需要我决定什么、接下来做什么、结果是否可信。

Flows 因此以人类与智能体的群组对话为起点，让双方在共同对话中工作，同时用少量明确的对象承载对话之外需要持续存在的工作：

Matter（业务事项）是一项需要持续负责的业务工作单元，拥有明确的范围、参与者、生命周期、权限和结果，不只是一段会话或一个任务标题。
Handoff（责任交接）把责任连同必要上下文、工作范围、预期输出和授权一起转移给下一个参与者，并由对方明确接受。
Work Record（工作记录）保留实际采取的行动、产生的结果及其证据，让团队能够检查、追溯和复盘工作。
Knowledge Promotion（知识提升）把经过验证的消息、证据和工作记录转化为可维护、可复用的知识，同时保留来源与审查关系。

普通交流仍然留在 Thread（会话）和 Message（消息）中；只有当一项工作需要独立事实、生命周期、权限或责任时，才进入这些更稳定的对象。这样既不会把聊天记录当成业务事实，也不会为了“平台完整”而把所有交流都变成复杂流程。

这意味着工作流也不必一开始就被固化成庞大的流程图。更自然的路径是：

先观察真实工作。
再沉淀可复用知识。
只有当重复程度和治理需要足以支撑时，才引入可执行工作流。

换句话说，Flows 不是先设计一个万能业务流程平台，再要求工作适应它；而是让可靠的工作方式从团队真实协作中生长出来。

知识如何在 Forma 与 Flows 之间流动

这套分工会带来一个必然问题：习惯 Forma 的专业团队不会愿意放弃文件、代码与自动化能力，完全迁入更受控的业务界面；但业务团队又需要使用这些专业团队维护的知识，并把运行中发现的新情况反馈回去。

如果解决方式只是“把两边数据全部同步”，很快会出现两个权威版本、编辑冲突、权限混乱和来源丢失。

更合理的思路是保留两边的独立权威：

Forma 仍是知识创作的权威来源。
Flows 负责治理知识在业务中的使用。

Forma 工作空间（Forma Workspace）可以作为基于 Git 的知识源，被 Flows 安装为工作空间数据源（Workspace Data Source）。专业团队继续在熟悉的代码仓库环境中维护内容；Flows 负责决定这些内容在哪个工作空间（Workspace）、项目（Project）、Matter、智能体或 Skill 范围内被使用，以及业务用户如何访问它。

这是一种集成（integration），而不是迁移（migration）。它避免了为了统一体验而消灭专业工作流，也避免了业务系统悄悄复制出另一份失去治理的知识。

只读集成只能解决“使用知识”，无法形成学习闭环。真实业务运行中会不断出现：规则不清楚、客户反复困惑、流程失效、知识过期、智能体缺少上下文，或者现场事实与既有文档不一致。

这些发现不应自动改写权威知识（canonical knowledge），也不应该只能停留在聊天里。更合理的反向贡献链是：

在这里，Proposal 与 Merge Request 必须承担不同职责：

Proposal 说明为什么应该改变、建议改变什么、依据和风险是什么。
Merge Request 说明具体文件将如何改变、验证是否通过、能否合入权威工作空间。

很多运行时发现非常有价值，却还不足以直接形成具体修改。例如“客户连续多次无法理解某个字段”是一个很好的 Proposal，但它并不能自动决定 Markdown 第几行应该改成什么。Proposal 为专业判断保留空间；Merge Request 则把判断落实为可审查的变更。

对于明确、低风险的修正，两步可以在界面上连成一条快路径（fast path），但语义边界仍然值得保留。

Proposal、Handoff 与薄的跨产品协议

在 Choral 当前的产品设计中，两个产品之间最值得共享的不是完整的 Task（任务）、Matter 或 Workflow 模型，也不是把 Forma 配置出的 Space 固化为跨产品原语，而是一层很薄的协作协议。

当前优先选择的两个对象是：

Proposal = 变更意图
Handoff  = 责任转移

Proposal 回答的是：

某项共享事实、状态或工作方式是否应该改变？

Handoff 回答的是：

接下来由谁继续推进，并携带哪些上下文、范围、期望与权限？

它们是正交原语（orthogonal primitive），而不是固定的父子关系。

有时先有 Proposal：团队接受了“应该升级退款规则”的建议，然后 Handoff 给合规团队完成规则定义。

有时先有 Handoff：Flows 把“这个流程频繁失败，请调查”的工作交给 Forma 中的知识维护团队，调查后再形成更新标准作业程序（SOP）的 Proposal。

Handoff 的接收者也不应该是产品名。真正接收责任的应该是参与者（Participant），例如人、智能体、团队（Team）、角色（Role）、队列（Queue）或工作组（Workgroup）；Forma、Flows、GitHub 或其他系统只是承载工作的界面。

一个有意义的 Handoff 至少需要表达：

来源工作与目的；
发起者（sender）与接收者（receiver）；
已知事实、证据和相关引用；
当前发现与未决问题；
接受的范围与允许的动作；
期待输出与验收条件（acceptance criteria）；
时限、风险与后续回传位置。

因此 Handoff 不是一条“请看一下”的消息，而是一份可接受、可拒绝、可完成、可撤销并可审计的责任关系。

为什么协议需要保持轻薄

在 Choral 对 Team Harness 问题的具体实现中，如果 Forma 与 Flows 共享整套领域模型（domain model），两边最终会相互绑死。更稳定的共享层可以只包含：

跨产品协作协议（cross-product collaboration protocol）
├── 参与者 / 身份引用（Participant / Identity Reference）
├── 资源 / 证据引用（Resource / Evidence Reference）
├── 来源 / 审计链接（Provenance / Audit Link）
├── Proposal
└── Handoff

这层协议只回答五件事：

谁在参与；
我们指向什么；
信息从哪里来；
建议改变什么；
由谁继续推进。

至于“工作本身是什么”，仍由各产品负责：Forma 拥有工作空间配置，并解释由配置投影出的 Space，以及 Entry（条目）、Schema、View、Operation（操作）和 Merge Request；Flows 则拥有 Thread、Message、Matter、Work Record 和 Workflow。

这种边界还有一个额外好处：它不会把跨产品协作限制在 Forma 与 Flows 之间。相同的 Handoff 可以从 Flows 指向 Forma，也可以从 Forma 指向 GitHub，从智能体指向人类审查者，或从业务团队指向外部专业系统。

把“尚未完成”变成一等状态（first-class state）

传统系统集成通常只关心读取、写入与同步。问题在于，真实协作中最重要的往往正是那些还没有完成的状态：

尚未接受
尚未归属
尚未落实
尚未审查
尚未完成

Proposal 和 Handoff 的价值，就是把这些中间态（intermediate state）显式化：

Proposal = 尚未被接受的变化
Handoff  = 尚未完成的责任转移

这对人类与智能体协作尤其重要。智能体可以发现问题、提出候选方案或准备 Handoff，但系统必须知道这些内容仍处于什么权威级别，是否有人接受了责任，以及何时才能成为稳定事实。

Team Harness 的治理能力，很大程度上就体现在它能否保留这些中间语义，而不是把每次生成都压扁成一次数据库写入。

形成持续学习的闭环

把这些概念放在一起，可以得到一条跨越业务运行与知识治理的循环：

这条链连接了两种通常分离的活动：

知识创作（knowledge authoring）：知识怎样被设计、解释、修正与治理；
业务采用（operational adoption）：知识怎样在真实工作中被采用、验证并产生结果。

Forma 中的一次合并并不一定意味着工作结束。新的 SOP、Skill 或规则可能还需要通过 Handoff 交给业务团队，在真实 Matter 或协作场景中试运行。反过来，Flows 中一次业务完成也不应只留下完成状态，它可能产生值得推广的经验、需要修正的知识或可以复用的工作方式。

这正是知识提升的意义：把情境化证据（situated evidence）转化为受维护知识（maintained knowledge），同时保留来源记录（provenance）、适用范围（scope）、归属（ownership）与审查信息，而不是让智能体记忆（Agent memory）或生成文本静默升级为权威事实。

这套产品思路的几条核心原则

1. 以工作为中心，而不是以智能体为中心

智能体是参与者，不是团队协作的最终容器。长期存在的工作、责任、上下文和结果才是中心。

2. 把智能体输出视为候选，而不是自动事实

运行时负责执行，应用边界负责校验，拥有该事实的产品对象负责提交。

3. 共享上下文不等于共享全部历史

对话需要经过提取、确认、定界和维护，才能成为未来可靠使用的共享上下文。

4. 保留产品独立性，只共享薄协议

Forma 与 Flows 不需要共享“工作是什么”，但需要共享“指向什么、建议什么、交给谁、从哪里来”。

5. 尊重权威事实来源（source of truth）

Forma 管理的代码仓库知识不应因为进入 Flows 就产生第二份不受治理的权威版本。Flows 运行中产生的候选知识也不应绕过审查直接写回权威工作空间。

6. 先观察真实工作，再抽象工作流

不要先建立庞大流程平台。先完成一个具体的人类与智能体工作闭环，观察重复模式，再把稳定模式提升为知识、Skill 或工作流。

7. 权限判断与环境隔离必须分层

批准机制回答“该不该做”，沙箱回答“最多能做到哪里”。团队场景还必须补上身份、委托授权、作用域与信息披露边界。

8. 不要过早建设通用事件总线（Event Bus）或信任矩阵（Trust Matrix）

领域模型可以为跨系统事件留出空间，但第一版更应该验证引用、Proposal 与 Handoff 是否解决了真实问题。基础设施应跟随已验证的协作需求生长。

结语：当 Harness 从智能体走向共同工作

Agent Harness 让一个模型获得了行动能力。它把模型连接到上下文、工具、Skill、运行环境和安全边界，使“回答问题”变成“完成工作”。

按本文的工作性定义，Team Harness 要解决的是更困难的一步：让不同的人和智能体在共同工作中保持上下文连续、责任明确、权限受控、结果可审查，并让今天发生的工作逐渐成为明天可以复用的知识与方法。

在这套思路中，Forma 与 Flows 分别守住两个重要表面：

Forma 的价值，是让专业团队继续使用文件、Git、编辑器、命令行与智能体，同时获得更可靠的共享上下文治理；Flows 的价值，是让更广泛的业务参与者不必理解这些底层机制，也能围绕真实工作与智能体可靠协作。

两者之间不靠“同步一切”消除边界，而是通过引用、提案、责任转移与来源关系跨越边界。

如果这个方向成立，未来企业中的智能体就不会只是散落在每个人电脑里的智能助手，也不会只是某个流程节点里的自动化机器人。它们会成为团队工作系统中的正式参与者：拥有明确身份，接受有限授权，获得适当上下文，产生候选结果，与人类相互交接责任，并在可审计的边界内共同推进工作。

而真正持续积累的，也不只是更多智能体会话，而是团队完成工作、修正认知和改善方法的能力。

核心概念速查

概念框架

概念	解决的问题	核心关注	不等于
Agent Harness	怎样让模型进入真实工作	上下文、工具、执行、权限和验证	模型本身或简单的工具集合
Team Harness	怎样让人类与智能体围绕共同工作保持连续性	共享上下文、责任、权限、审计和知识改进	多智能体编排或既成行业品类

Choral 的产品实现

产品	主要职责	工作方式	边界
Choral Forma	创作和治理专业共享上下文	文件、Markdown、Git、配置与专业工具	不是 Flows 的后台，也不只是 Markdown 编辑器
Choral Flows	组织和运行人类与智能体的共同工作	对话、Matter、Handoff、Work Record 与业务治理	不是 Forma 的简化版，也不是万能流程平台

Team Harness 是本文用于理解团队级人机协作问题的框架与产品理念；Forma 与 Flows 是 Choral 对这一问题的一种双产品实现。

从两个项目继续了解

Choral 通过两个独立项目实现上述方向：

Forma 是开源项目。产品文档、设计决策、示例和研发知识都在公开的 GitHub 仓库中，读者可以直接阅读，也可以克隆到本地交给自己熟悉的智能体分析。
Flows 是闭源商业项目，不提供公开代码仓库。它与 Forma 独立发展，并通过知识引用、Proposal 和 Handoff 共同支撑本文讨论的 Team Harness。

了解 Forma 不必先读完一套产品手册。可以打开 Codex、Claude Code、OpenCode 或其他熟悉的智能体应用，从下面这句话开始：

请将 https://github.com/choral-io/choral-forma 克隆到当前工作目录。完成后进入项目，先阅读 Installing Forma 说明和仓库中的产品文档、设计决策与实际工作区配置，向我介绍 Forma 的核心理念、当前能力，以及它与 Flows 在本文所述 Team Harness 问题中的分工。不要修改文件；需要安装 Forma CLI 时，先说明步骤并等待我确认。

这样，读者可以先从 Forma 公开、可检查的实际工作区理解产品，再回到本文判断：自己的团队真正缺少的是一个更强的智能体，还是让人类与智能体围绕共同工作保持连续性的系统能力。