Agent-to-Agent 协议
回答“如何协作”：Agent 怎样被发现，怎样表达能力，如何交换任务、状态、消息和产物。
- 身份与能力描述
- 任务与消息交换
- 状态同步与协商
- 跨平台互操作
AGENT-TO-AGENT · GOVERNANCE HARNESS
让 Agent
互相理解，
也让结果值得信任。
Agent-to-Agent 协议处理连接、能力描述与任务交换；协作 Harness 管理上下文、承诺、证据与验收。 一个让协作发生，另一个让协作可追溯、可验证。
01PROTOCOL发现 · 消息 · 协商
协作事件
02HARNESS上下文 · 提交 · 验收
核心判断
多 Agent 系统最难的部分，不是让更多 Agent 开始工作，而是知道它们为什么这样工作、交付了什么，以及我们凭什么相信结果。
01 · A USEFUL DISTINCTION
协议负责连接，
Harness 负责治理。
Multi-Agent Harness
回答“如何可信地协作”：上下文从哪里来，谁能修改什么，交付如何进入主线，验收证据是否充分。
- 上下文与所有权边界
- 事件账本与变更证据
- 提交门与回滚点
- 独立验证与缺陷回流
02 · FOUR MECHANISMS
从“它说做完了”
到“证据表明可以交付”。
EventLog
追加式协作事件账本。记录主体、动作、输入、产物和状态变化，让关键决定可以回放。
Context Capsule
把任务需要的背景、约束、依赖和完成标准压缩成可传递上下文，减少隐性假设在交接中丢失。
Commit Gate
在改动进入共享主线前核对所有权、测试、证据和影响范围。局部绿灯不自动等于整体完成。
Independent Verification
由独立视角按原始目标验收；发现问题就形成 finding，并回到修复—复验闭环，而不是停在口头确认。
03 · THE WORKING LOOP
一条最小的
协作证据循环。
- 01定义任务
目标、边界、所有权、完成标准。
- 02封装上下文
只传递完成任务所需的可靠信息。
- 03执行与留痕
探索可以自由，关键动作进入事件账本。
- 04通过提交门
检查变更、测试、依赖和回滚点。
- 05目标端读回
从权威目标系统读取实际 Effect，而不是只看工具自报成功。
- 06独立验收
由责任主体回到原始目标，对读回结果作出显式决定。
MATURITY & CLAIM BOUNDARY
开源实现正在持续演进，
理念不替代运行证据。
Flowness 是 ToWow 团队公开的协作 Harness 实现。公开 Alpha 已展示确定性的执行、评审、定向返工，以及对后继候选的新 verdict；这个 verdict 不等于目标域 Effect 或责任主体的现实验收。这里其余内容描述的是稳定的设计方向。具体功能、测试覆盖和运行状态，应以对应版本的代码、记录和验收证据为准。
我们刻意区分“已规划”“本地通过”“已部署”和“真实环境已验证”。如果一项主张没有足够证据，它就仍然是未验证。
本页中的 Agent-to-Agent 是多 Agent 协作的通用表述，不代表已经兼容某个特定外部 A2A 标准。
在 GitHub 查看当前实现 ↗04 · QUESTIONS
常见问题。
01Agent-to-Agent 协议和 Harness 是同一件事吗？
不是。协议主要处理身份、能力、消息和任务如何交换；Harness 管理协作过程中的上下文、提交边界、证据、验收和追责。两者互补。
02有了模型调用日志，为什么还需要 EventLog？
普通日志记录程序发生了什么，协作事件账本还要表达谁在什么上下文中做了什么决定、依据是什么、产物如何进入下一阶段，以及验收结论如何形成。
03Harness 会限制 Agent 的创造力吗？
良好的 Harness 约束的是承诺、证据和变更边界，而不是推理路径。Agent 可以自由探索，但不能把探索结果直接当作已经交付或已经验证。
继续探索