从 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：

这些类别并不互斥。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

这层协议只回答五件事：

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

至于“工作本身是什么”，仍由各产品负责：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 的价值，是让更广泛的业务参与者不必理解这些底层机制，也能围绕真实工作与智能体可靠协作。

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

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

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

核心概念速查

概念框架

Choral 的产品实现

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 公开、可检查的实际工作区理解产品，再回到本文判断：自己的团队真正缺少的是一个更强的智能体，还是让人类与智能体围绕共同工作保持连续性的系统能力。