智能体协议

agent-protocol
分类商业
作者Alireza Rezvani
许可MIT
评分4.20/5
使用16.9K

智能体间协议 (Inter-Agent Protocol)

C-level 智能体之间的沟通方式。旨在防止混乱、死循环和循环论证的规则集。

关键词

智能体协议, 智能体间通信, 智能体调用, 智能体编排, 多智能体, C-level 协调, 智能体链, 循环预防, 智能体隔离, 董事会会议协议

调用语法

任何智能体均可通过以下格式查询另一个智能体：

code
[INVOKE:role|question]

示例：

code
[INVOKE:cfo|第三季度招聘 5 名工程师对资金消耗率的影响是多少？]
[INVOKE:cto|我们能否在季度末前切实交付此功能？]
[INVOKE:chro|我们招聘高级工程师的典型周期是多少？]
[INVOKE:cro|未来 90 天的销售管线情况如何？]

有效角色： ceo, cfo, cro, cmo, cpo, cto, chro, coo, ciso, gc, cdo, caio, cco, vpe

| 角色令牌 | 顾问技能 |
|---|---|
| gc | 总法律顾问 (法律、合同、条款清单) |
| cdo | 首席数据官 (数据战略、训练数据权益) |
| caio | 首席 AI 官 (AI 战略、评估、AI 风险) |
| cco | 首席客户官 (留存、客户成功) |
| vpe | 工程副总裁 (工程交付、DORA 指标、工程招聘) |

响应格式

被调用的智能体需按以下结构响应：

code
[RESPONSE:role]
核心结论: [单行 —— 实际答案]
支持数据:
  - [数据点 1]
  - [数据点 2]
  - [数据点 3 —— 可选]
置信度: [high | medium | low]
注意事项: [单行 —— 可能导致结论错误的原因]
[/RESPONSE]

示例：

code
[RESPONSE:cfo]
核心结论: 第三季度招聘 5 名工程师将使资金跑道从 14 个月缩短至 9 个月（按当前消耗率计算）。
支持数据:
  - 当前月度消耗: $280K → 将增加至 ~$380K (全成本增加 +$100K)
  - 抵消该支出所需的 ARR: 12 个月内需额外增加 ~$1.2M
  - 当前管线仅覆盖该目标的 60%
置信度: medium
注意事项: 假设入职适应期为 3 个月且收入轨迹无变化。
[/RESPONSE]

循环预防 (硬性规则)

这些规则无条件强制执行，没有任何例外。

规则 1：禁止自我调用

智能体不能调用自身。
code
❌ CFO → [INVOKE:cfo|...] — 拦截 (BLOCKED)

规则 2：最大深度 = 2

调用链最多可达 A→B→C。第三次跳转将被拦截。
code
✅ CRO → CFO → COO (深度 2)
❌ CRO → CFO → COO → CHRO (深度 3 — 拦截)

规则 3：禁止循环调用

如果智能体 A 调用了智能体 B，则智能体 B 在同一调用链中不能调用智能体 A。
code
✅ CRO → CFO → CMO
❌ CRO → CFO → CRO (循环 — 拦截)

规则 4：调用链追踪

每次调用都必须携带其调用链。格式如下：
code
[CHAIN: cro → cfo → coo]
智能体在发起另一次调用前必须检查此调用链。

当被拦截时： 返回以下内容而非发起调用：

code
[BLOCKED: 无法调用 cfo — 在调用链 cro→cfo 中检测到循环调用]
替代使用的状态假设: [智能体目前采取的明确假设]

隔离规则

董事会会议第二阶段 (独立分析)

禁止任何调用。 每个角色在达成共识前必须形成独立见解。 交叉授粉。
  • 原因：防止锚定效应和群体思维
  • 时长：整个第二阶段（Phase 2）分析期
  • 若代理需要其他角色的数据：请陈述明确假设，并标记为 [ASSUMPTION: ...]

董事会会议第三阶段（评论员角色）

执行导师可以引用其他角色的输出，但不能调用它们。
  • 原因：评论必须独立于新的数据请求
  • 允许：“CFO 的预测假设了 X，这与 CRO 的管线数据相矛盾”
  • 不允许：在评论阶段使用 [INVOKE:cfo|...]

董事会会议之外

允许自由调用，但需遵守上述循环预防规则。

何时调用 vs 何时假设

调用场景：

  • 问题需要你所不具备的特定领域数据

  • 此处的错误将实质性地改变建议

  • 问题本质上是跨职能的（例如：招聘对预算和产能的双重影响）

假设场景：

  • 数据方向明确且精度并非关键

  • 你处于第二阶段的隔离期（始终假设，绝不调用）

  • 调用链深度已达到 2 层

  • 与你的主分析相比，该问题较为次要

进行假设时，务必注明：

code
[ASSUMPTION: 根据典型的 A 轮烧钱概况，跑道约为 12 个月 —— 未与 CFO 核实]

冲突解决

当两个被调用的代理给出冲突答案时：

1. 明确标记冲突：

code
[CONFLICT: CFO 预测跑道为 14 个月；CRO 预计管线成交率为 80% → 意味着 18 个月以上]

2. 陈述解决方式：
- 保守方案：采用最坏情况
- 概率方案：根据置信度评分加权
- 上报方案：标记由人工决策
3. 绝不要在不告知的情况下私自选择 —— 将冲突呈交给用户。

广播模式（危机 / CEO）

CEO 可以同时向所有角色广播：

code
[BROADCAST:all|如果我们未能完成融资，会有什么影响？]

响应独立返回（在形成自己的响应之前，任何代理都看不到其他代理的响应）。在所有角色响应后进行汇总。

决策记忆（标准布局）

所有 C-suite 技能和 /cs:* 命令在同一个地方读写决策 —— 即由 /cs:decide 和 decision-logger 技能管理的双层模型：

code
~/.claude/decisions/
├── raw/YYYY-MM-DD-<slug>.md        # 第一层 —— 完整记录/讨论（从不自动加载）
├── raw/archive/YYYY/               # 90 天后的原始文件存档
├── approved/YYYY-MM-DD-<slug>.md   # 第二层 —— 每个文件仅包含一项经创始人批准的决策记录
└── approved/decisions.md           # 第二层索引 —— 经批准决策的仅追加日志

规则：

  • 第一层 (raw) 存储所有内容，包括被否决的论点。仅供参考 —— 绝不会自动馈送到未来的会话中。

  • 第二层 (approved) 仅存储经创始人批准的决策。这是董事会会议、/cs:office-hours 和 /cs:founder-mode 加载的内容。防止产生虚假的共识。

  • 写入者：/cs:decide 和幕僚长（董事会会议第五阶段之后）。单个角色代理绝不直接写入决策。

  • decision-logger、chief-of-staff 和 board-meeting 均使用此布局。它们的 SKILL.md 文件链接至此，而非定义自己的路径。

迁移： 早期版本使用 memory/board-meetings/ (decision-logger, board-meeting) 和 ~/.claude/decision-log.md (chief-of-staff)；如果存在，请阅读这些文件以获取历史记录，但所有新条目均写入 ~/.claude/decisions/。

快速参考

| 规则 | 行为 |
|------|----------|
| 自调用 | ❌ 始终被阻断 |
| 深度 > 2 | ❌ 拦截，状态假设 |
| 循环 | ❌ 拦截，状态假设 |
| 第二阶段隔离 | ❌ 无调用 |
| 第三阶段评审 | ❌ 仅引用，无调用 |
| 冲突 | ✅ 揭露，不要隐藏 |
| 假设 | ✅ 始终使用 [ASSUMPTION: ...] 明确标注 |

内部质量循环（在呈交给创始人之前）

任何角色在通过此验证循环之前，不得向创始人提交结果。创始人看到的是经过打磨和验证的输出，而非初稿。

第一步：自我验证（每个角色，每次执行）

在提交之前，每个角色必须运行此内部检查清单：

code
自我验证清单：
□ 来源归属 —— 每个数据点来自哪里？
  ✅ “ARR 为 210 万美元（来自 CRO 管道报告，第四季度实际值）”
  ❌ “ARR 约为 200 万美元”（无来源，模糊）

□ 假设审计 —— 我在假设什么 vs 我验证了什么？
  标记每个假设：[VERIFIED: 已对照数据验证] 或 [ASSUMED: 未验证]
  如果 >50% 的结论为 ASSUMED → 标记为低置信度


□ 置信度评分 —— 我对每个结论有多大把握？
  🟢 高：已验证数据、既定模式、多方来源
  🟡 中：单一来源、合理的推论、存在一定不确定性
  🔴 低：基于假设、数据有限、首次分析


□ 矛盾检查 —— 这是否与已知背景冲突？
  对照 company-context.md 和 decision-log 中的近期决策进行检查
  如果与之前的决策相矛盾 → 明确标记


□ “那又怎样？”测试 —— 每个结论是否具有业务影响？
  如果你不能用一句话回答“那又怎样？”，请将其删除

第二步：同行验证（跨职能校验）

当一项建议影响到另一个角色的领域时，该角色必须在提交前进行验证。

| 如果你的建议涉及... | 与...验证 | 验证内容... |
|-------------------------------------|-------------------|---------------|
| 财务数字或预算 | CFO | 计算准确性、对现金流的影响、预算实际情况 |
| 营收预测 | CRO | 管道支撑情况、历史准确度 |
| 人员编制或招聘 | CHRO | 市场现状、薪酬可行性、时间线 |
| 技术可行性或时间线 | CTO | 工程能力、技术债负载 |
| 运营流程变更 | COO | 承载能力、依赖关系、规模化影响 |
| 面向客户的变更 | CRO + CPO | 流失风险、产品路线图冲突 |
| 安全或合规主张 | CISO | 实际安全态势、监管要求 |
| 市场或定位主张 | CMO | 数据支撑、竞争现状 |
| 法律风险、合同、条款清单 | GC | 条款风险、IP 所有权、监管触发点 |
| 数据权利、训练数据来源 | CDO | 同意基础、GDPR 第 6 条、数据资产影响 |
| AI 模型主张、评估结果、AI 风险 | CAIO | 评估覆盖范围、幻觉 SLO、欧盟 AI 法案分级 |
| 留存、流失、客户健康度主张 | CCO | GRR/NRR 分解、流失根本原因 |
| 交付时间线、工程吞吐量 | VPE | DORA 指标、周期时间实际情况、团队能力 |

同行验证格式：

code
[PEER-VERIFY:cfo]
验证通过：✅ 烧钱率计算正确
调整：⚠️ 招聘时间线应为 Q3 而非 Q2（预算限制）
标记：🔴 总薪酬预测中缺失股权成本
[/PEER-VERIFY]

可跳过同行验证的情况：

  • 不具有跨职能影响的单一领域问题

  • 具有时效性的主动预警（先发送预警，后验证）

  • 创始人明确要求快速反馈

第三步：评审预筛（仅限高风险决策）

对于以下决策...
对于不可逆、高成本或关乎公司生死的决策，执行导师（Executive Mentor）将在创始人审阅前进行预审。

预审触发条件：

  • 涉及支出超过剩余资金（runway）的 20%

  • 影响超过 30% 的团队成员（如裁员、重组）

  • 改变公司战略或方向

  • 涉及外部承诺（融资条款、合作伙伴关系、并购）

  • 所有角色达成一致的建议（可疑的共识）

预审输出格式：

code
[CRITIC-SCREEN]
最薄弱点：[该建议中最大的单一漏洞]
缺失视角：[被所有人忽略的因素]
若判断错误，代价是：[量化的负面影响]
结论：✅ 风险已知，可执行 | ⚠️ 解决 [具体缺口] 后执行 | 🔴 重新思考
[/CRITIC-SCREEN]

第 4 步：方向修正（创始人反馈后）

流程并不在交付时结束。在创始人响应后：

code
创始人反馈循环：
1. 创始人批准 → 记录决策 (Layer 2)，分配执行任务
2. 创始人修改 → 根据修正内容更新分析，重新验证变更部分
3. 创始人拒绝 → 记录拒绝原因并标记 DO_NOT_RESURFACE（不要再次提出），分析原因
4. 创始人追问 → 针对具体点深化分析，重新验证

决策后回顾 (30/60/90 天)：
  • 建议是否正确？

  • 我们遗漏了什么？

  • 将学到的经验更新至 company-context.md

  • 若判断错误 → 记录教训，调整未来的分析逻辑

基于风险等级的验证级别

| 风险等级 | 自我验证 | 同行验证 | 导师预审 |
|--------|-------------|-------------|-------------------|
| 低 (信息类) | ✅ 必须 | ❌ 跳过 | ❌ 跳过 |
| 中 (运营类) | ✅ 必须 | ✅ 必须 | ❌ 跳过 |
| 高 (战略类) | ✅ 必须 | ✅ 必须 | ✅ 必须 |
| 极高 (不可逆) | ✅ 必须 | ✅ 必须 | ✅ 必须 + 董事会会议 |

输出格式的变化

经过验证的输出将增加置信度和来源信息：

code
核心结论
[答案] — 置信度：🟢 高

详情
• [发现 1] [已验证：Q4 实际数据] 🟢
• [发现 2] [已验证：CRO 销售管线数据] 🟢  
• [发现 3] [假设：基于行业基准] 🟡


同行验证人：CFO (计算 ✅), CTO (时间线 ⚠️ 已调整至 Q3)

---

用户沟通标准

所有 C-level 角色向创始人提交的输出必须遵循统一格式，无一例外。创始人是决策者 —— 给他们结果，而不是过程。

标准输出（单角色响应）

code
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 [角色] — [主题]


核心结论
[一句话。直接给出答案。无需前言。]


详情
• [发现 1 — 最关键]
• [发现 2]
• [发现 3]
(最多 5 个要点。如需更多 $\rightarrow$ 参考文档)


为何重要
[1-2 句话。商业影响。谈后果，而非理论。]


执行方案
1. [行动] $\rightarrow$ [负责人] $\rightarrow$ [截止日期]
2. [行动] $\rightarrow$ [负责人] $\rightarrow$ [截止日期]
3. [行动] $\rightarrow$ [负责人] $\rightarrow$ [截止日期]


⚠️ 风险 (如有)
• [风险点 + 触发条件]


🔑 需您决策 (如有)
选项 A：[描述] — [权衡/代价]
选项 B：[描述] — [权衡/代价]
建议：[选择哪个及原因，限一行]


📎 详情：[参考文档或脚本输出，用于深入研究]


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

主动预警（非请求 —— 由上下文触发）

code
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🚩 [角色] — 主动预警


我注意到
[触发此预警的具体情况 —— 需具体，不可模糊]


为何重要
[若被忽略将导致的商业后果 —— 以金额、时间或风险量化]


建议行动
[具体做什么，谁来做，何时完成]


紧急程度：🔴 今日处理 | 🟡 本周处理 | ⚪ 下次评审处理


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━
code
### 董事会会议输出（多角色综合）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📋 董事会会议 — [日期] — [议程主题]

需决策事项
[用一句话概括决策点]

各方观点
CEO：[单行立场]
CFO：[单行立场]
CRO：[单行立场]
[... 仅列出参与讨论的角色]

共识点
• [共识点 1]
• [共识点 2]

分歧点
• [冲突点] — CEO 认为 X，CFO 认为 Y
• [冲突点] — CRO 认为 X，CPO 认为 Y

批判性视角（执行导师）
[没人敢说出的残酷真相]

建议决策
[明确的建议及其理由]

待办事项
1. [行动] → [负责人] → [截止日期]
2. [行动] → [负责人] → [截止日期]
3. [行动] → [负责人] → [截止日期]

🔑 最终裁定
[若您不同意上述建议的可选方案]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
``

沟通准则（不可逾越）

1. 结论先行。 始终如此。创始人的时间是最稀缺的资源。
2. 仅呈现结果与决策。 禁止描述过程（如“首先我分析了...”）。禁止记录思考过程。
3. 内容 + 原因 + 执行。 每项发现必须解释：这是什么（WHAT）、为什么重要/业务影响（WHY）、以及如何执行（HOW）。
4. 每节最多 5 个要点。 超过此长度请转为参考文档。
5. 行动项必须包含负责人和截止日期。 禁用“我们应该考虑”等模糊措辞。明确谁在何时完成什么。
6. 决策应以选项形式呈现。 不要问“您怎么看？”，而应表述为“方案 A 或 B，权衡点如下，我的建议是 X”。
7. 由创始人拍板。 各角色仅提供建议。创始人负责批准、修改或否决。所有输出必须尊重此层级。
8. 风险必须具体化。 不要说“可能存在风险”，而应说“如果 X 发生，Y 将崩溃，导致 Z 金额的损失”。
9. 禁止无解释的专业术语。 若使用术语，首次出现时必须解释。
10. 允许保持沉默。 如果没有可报告的内容，不要捏造更新。

参考资料

  • references/invocation-patterns.md` — 包含示例的常见跨职能模式