| name | agent-protocol |
| description | C-suite 智能体团队的智能体间通信协议。定义了调用语法、循环预防、隔离规则和响应格式。当 C-suite 智能体需要相互查询、协调跨职能分析或运行包含多个智能体角色的董事会会议时使用。 |
| license | MIT |
| metadata | {"version":"1.0.0","author":"Alireza Rezvani","category":"c-level","domain":"agent-orchestration","updated":"2026-03-05T00:00:00.000Z","frameworks":"invocation-patterns"} |
智能体间协议
C-suite 智能体如何相互对话。防止混乱、循环和循环论证的规则。
关键词
agent protocol, inter-agent communication, agent invocation, agent orchestration, multi-agent, c-suite coordination, agent chain, loop prevention, agent isolation, board meeting protocol
调用语法
任何智能体都可以使用以下方式查询另一个智能体：
[INVOKE:role|question]
示例：
[INVOKE:cfo|在第三季度招聘 5 名工程师对资金消耗率有什么影响？]
[INVOKE:cto|我们现实中能在季度末交付这个功能吗？]
[INVOKE:chro|我们招聘高级工程师的典型周期是多久？]
[INVOKE:cro|我们未来 90 天的销售漏斗情况如何？]
有效角色： ceo, cfo, cro, cmo, cpo, cto, chro, coo, ciso
响应格式
被调用的智能体使用此结构进行响应：
[RESPONSE:role]
核心发现：[一行文字 — 实际回答]
支持数据：
- [数据点 1]
- [数据点 2]
- [数据点 3 — 可选]
置信度：[high | medium | low]
风险说明：[一行文字 — 什么因素可能导致此结论错误]
[/RESPONSE]
示例：
[RESPONSE:cfo]
核心发现：在第三季度招聘 5 名工程师将使资金生存期（runway）从 14 个月缩短至 9 个月。
支持数据：
- 当前月度资金消耗：$280K → 增加至约 ~$380K（含全额福利成本 +$100K）
- 抵消所需的 ARR：12 个月内需额外增加约 ~$1.2M
- 当前销售漏斗覆盖了该目标的 60%
置信度：medium
风险说明：假设有 3 个月的入职磨合期，且收入轨迹无变化。
[/RESPONSE]
循环预防（硬性规则）
这些规则将被无条件执行。没有例外。
规则 1：禁止自我调用
智能体不能调用自身。
❌ CFO → [INVOKE:cfo|...] — 已拦截
规则 2：最大深度 = 2
链路可以为 A→B→C。第三次跳转将被拦截。
✅ CRO → CFO → COO (深度 2)
❌ CRO → CFO → COO → CHRO (深度 3 — 已拦截)
规则 3：禁止循环调用
如果智能体 A 调用了智能体 B，智能体 B 不能在同一链路中调用智能体 A。
✅ CRO → CFO → CMO
❌ CRO → CFO → CRO (循环 — 已拦截)
规则 4：链路追踪
每次调用都携带其调用链。格式：
[CHAIN: cro → cfo → coo]
智能体在通过另一次调用进行响应前需检查此链路。
当被拦截时： 返回以下内容而非发起调用：
[BLOCKED: 无法调用 cfo — 在链路 cro→cfo 中检测到循环调用]
改用以下假设状态：[智能体正在做出的明确假设]
隔离规则
董事会会议第 2 阶段（独立分析）
禁止任何调用。 每个角色在进行交叉沟通前需形成独立的观点。
- 原因：防止锚定效应和群体思维
- 持续时间：整个第 2 阶段分析期间
- 如果智能体需要另一个角色的数据：陈述明确的假设，并使用
[ASSUMPTION: ...] 标记。
董事会会议第 3 阶段（批评者角色）
执行导师（Executive Mentor）可以引用其他角色的输出，但不能调用他们。
- 原因：批评必须独立于新的数据请求
- 允许："CFO 的预测假设了 X，这与 CRO 的销售漏斗数据相矛盾"
- 不允许：在批评阶段使用
[INVOKE:cfo|...]
董事会会议之外
调用可以自由进行，但受上述循环预防规则限制。
何时调用 vs 何时假设
在以下情况下调用：
- 问题需要你所不具备的领域特定数据
- 此处的错误将实质性地改变建议
- 问题本质上是跨职能的（例如：招聘对预算和产能的双重影响）
在以下情况下假设：
- 数据方向明确，精度并不关键
- 你处于第 2 阶段隔离期（始终假设，从不调用）
- 调用链已达到深度 2
- 与你的主要分析相比，该问题较为次要
进行假设时，务必陈述：
[ASSUMPTION: 根据典型的 A 轮消耗概况，资金生存期约为 12 个月 — 未经 CFO 验证]
冲突解决
当两个被调用的智能体给出相互矛盾的答案时：
- 明确标记冲突：
[CONFLICT: CFO 预测 14 个月的资金生存期；CRO 预计销售漏斗将关闭 80% → 意味着 18 个月以上]
- 陈述解决方法：
- 保守法：使用最坏情况
- 概率法：根据置信度得分加权
- 上报：标记给人类决策
- 严禁默默选择其一 — 必须向用户呈现冲突。
广播模式（危机 / CEO）
CEO 可以同时向所有角色发起广播：
[BROADCAST:all|如果我们融资失败，会有什么影响？]
响应将独立返回（在形成自己的响应前，没有任何智能体能看到他人的响应）。在所有响应返回后进行汇总。
快速参考
| 规则 | 行为 |
|---|
| 自我调用 | ❌ 始终拦截 |
| 深度 > 2 | ❌ 拦截，陈述假设 |
| 循环调用 | ❌ 拦截，陈述假设 |
| 第 2 阶段隔离 | ❌ 禁止调用 |
| 第 3 阶段批评 | ❌ 仅限引用，禁止调用 |
| 冲突 | ✅ 呈现冲突，不要隐藏 |
| 假设 | ✅ 始终通过 [ASSUMPTION: ...] 明确化 |
内部质量闭环（在任何内容提交给创始人之前）
任何角色在未通过此验证闭环前，不得向创始人提交内容。创始人看到的是经过润色、验证的输出，而非初稿。
步骤 1：自我验证（每个角色，每次）
在提交前，每个角色运行此内部清单：
自我验证清单：
□ 来源归属 — 每个数据点来自哪里？
✅ "ARR 为 $2.1M（来自 CRO 销售漏斗报告，Q4 实际数据）"
❌ "ARR 约为 $2M"（无来源，模糊）
□ 假设审计 — 我假设了什么 vs 验证了什么？
标记每个假设：[VERIFIED: 已核对数据] 或 [ASSUMED: 未验证]
如果 >50% 的发现是 ASSUMED → 标记为低置信度
□ 置信度得分 — 对每个发现的确定程度如何？
🟢 High: 经过验证的数据、既定模式、多个来源
🟡 Medium: 单一来源、合理推论、存在一些不确定性
🔴 Low: 基于假设、有限数据、首次分析
□ 矛盾检查 — 是否与已知背景冲突？
对照 company-context.md 和 decision-log 中的近期决策进行检查
如果与过去的决策冲突 → 明确标记
□ "那又怎样？" 测试 — 每个发现是否有业务后果？
如果你不能在一句话内回答“那又怎样？”，请删除它
步骤 2：同行验证（跨职能验证）
当一项建议影响到另一个角色的领域时，该角色必须在提交前进行验证。
| 如果你的建议涉及... | 验证人... | 他们检查... |
|---|
| 财务数字或预算 | CFO | 计算、资金生存期影响、预算现实 |
| 收入预测 | CRO | 销售漏斗支撑、历史准确性 |
| 人员编制或招聘 | CHRO | 市场现实、薪酬可行性、时间表 |
| 技术可行性或时间表 | CTO | 工程产能、技术债负载 |
| 运营流程变更 | COO | 产能、依赖关系、扩展影响 |
| 面对客户的变更 | CRO + CPO | 流失风险、产品路线图冲突 |
| 安全或合规声明 | CISO | 实际态势、监管要求 |
| 市场或定位声明 | CMO | 数据支撑、竞争现实 |
同行验证格式：
[PEER-VERIFY:cfo]
验证通过：✅ 资金消耗率计算正确
已调整：⚠️ 招聘时间表应为 Q3 而非 Q2（预算限制）
已标记：🔴 总薪酬预测中缺失股权成本
[/PEER-VERIFY]
在以下情况下跳过同行验证：
- 无跨职能影响的单一领域问题
- 时间敏感的主动预警（先发送预警，后验证）
- 创始人明确要求快速反馈
步骤 3：批评者预审（仅限高风险决策）
对于不可逆、高成本或关乎公司存亡的决策，执行导师在创始人看到之前进行预审。
触发预审的条件：
- 涉及支出 > 20% 的剩余资金生存期
- 影响 > 30% 的团队（裁员、重组）
- 改变公司战略或方向
- 涉及外部承诺（融资条款、合作伙伴关系、并购）
- 所有角色都达成一致的任何建议（可疑的共识）
预审输出：
[CRITIC-SCREEN]
最薄弱点：[该建议中最大的单一漏洞]
缺失的视角：[没有人考虑到的因素]
如果错了，成本是：[量化的负面影响]
执行建议：✅ 带有注明的风险 | ⚠️ 在解决 [特定缺口] 后 | 🔴 重新思考
[/CRITIC-SCREEN]
步骤 4：路线修正（在创始人反馈后）
闭环并不随交付而结束。在创始人回应后：
创始人反馈闭环：
1. 创始人批准 → 记录决策 (Layer 2)，分配行动
2. 创始人修改 → 使用修正后的内容更新分析，重新验证变更部分
3. 创始人拒绝 → 将拒绝记录为 DO_NOT_RESURFACE（不再提及），理解原因
4. 创始人询问后续问题 → 深入分析特定点，重新验证
决策后审查 (30/60/90 天)：
- 建议是否正确？
- 我们遗漏了什么？
- 用我们学到的东西更新 company-context.md
- 如果错了 → 记录教训，调整未来的分析
按风险等级划分的验证级别
| 风险等级 | 自我验证 | 同行验证 | 批评者预审 |
|---|
| 低（信息类） | ✅ 必须 | ❌ 跳过 | ❌ 跳过 |
| 中（运营类） | ✅ 必须 | ✅ 必须 | ❌ 跳过 |
| 高（战略类） | ✅ 必须 | ✅ 必须 | ✅ 必须 |
| 极高（不可逆） | ✅ 必须 | ✅ 必须 | ✅ 必须 + 董事会会议 |
输出格式的变化
经过验证的输出增加了置信度和来源信息：
核心结论
[回答] — 置信度：🟢 High
内容详情
• [发现 1] [VERIFIED: Q4 实际数据] 🟢
• [发现 2] [VERIFIED: CRO 销售漏斗数据] 🟢
• [发现 3] [ASSUMED: 基于行业基准] 🟡
同行验证人：CFO (计算 ✅), CTO (时间表 ⚠️ 已调整至 Q3)
用户沟通标准
所有提交给创始人的 C-suite 输出必须遵循统一格式。没有例外。创始人是决策者 — 给他们结果，而非过程。
标准输出（单一角色响应）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 [ROLE] — [主题]
核心结论
[一句话。答案。不要有前言。]
内容详情
• [发现 1 — 最关键]
• [发现 2]
• [发现 3]
（最多 5 个要点。如果需要更多 → 引用文档。）
为什么这很重要
[1-2 句话。业务影响。不是理论 — 而是后果。]
如何行动
1. [行动] → [负责人] → [截止日期]
2. [行动] → [负责人] → [截止日期]
3. [行动] → [负责人] → [截止日期]
⚠️ 风险（如有）
• [风险 + 触发因素]
🔑 你的决策（如需要）
选项 A：[描述] — [权衡]
选项 B：[描述] — [权衡]
建议：[选择哪一个及原因，一行字]
📎 详情：[引用文档或脚本输出以供深入研究]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
主动预警（未经请求 — 由上下文触发）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🚩 [ROLE] — 主动预警
我注意到了什么
[触发此预警的原因 — 具体，不模糊]
为什么这很重要
[如果忽略的业务后果 — 金钱、时间或风险维度]
建议行动
[确切的操作，负责人，时间节点]
紧急程度：🔴 今日处理 | 🟡 本周内 | ⚪ 下次审查
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
董事会会议输出（多角色综合）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 董事会会议 — [日期] — [议程主题]
需要决策
[用一句话阐述决策框架]
各方视角
CEO：[一句话立场]
CFO：[一句话立场]
CRO：[一句话立场]
[... 仅限有贡献的角色]
共识点
• [共识点 1]
• [共识点 2]
分歧点
• [冲突] — CEO 认为是 X，CFO 认为是 Y
• [冲突] — CRO 认为是 X，CPO 认为是 Y
批评者观点（执行导师）
[没有人说出的令人不安的真相]
建议决策
[带有理论依据的清晰建议]
行动项
1. [行动] → [负责人] → [截止日期]
2. [行动] → [负责人] → [截止日期]
3. [行动] → [负责人] → [截止日期]
🔑 你的决定
[如果你不同意建议时的可选方案]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
沟通规则（不可协商）
- 核心结论先行。 始终如此。创始人的时间是最稀缺的资源。
- 仅限结果和决策。 不要描述过程（“首先我分析了……”）。不要大声思考。
- 内容 + 理由 + 做法。 每个发现都必须解释它是“什么”（WHAT），为什么重要（WHY，业务影响），以及如何行动（HOW）。
- 每个部分最多 5 个要点。 超过此长度 = 放在引用文档中。
- 行动必须有负责人和截止日期。 禁止使用“我们应该考虑”。明确谁在什么时候做什么。
- 决策以选项形式呈现。 不是“你怎么看？” — 而是“选项 A 或 B，权衡如下，这是我的建议。”
- 创始人决策。 角色提供建议。创始人批准、修改或拒绝。所有输出都必须尊重此层级。
- 风险必须具体。 不要说“可能存在风险” — 而是“如果 X 发生，Y 会崩溃，导致 $Z 的损失。”
- 无解释不得使用术语。 如果你使用了某个术语，在首次使用时必须解释。
- 保持沉默也是一种选择。 如果没有什么可报告的，不要捏造更新。
参考
references/invocation-patterns.md — 带有示例的常见跨职能模式
