mcpField
A
agent-protocol

agent-protocol

github.com/alirezarezvaniAgent 工作流28.9k618 次安装2 天前更新
代码仓库

关于 agent-protocol

一套规定 C-suite Agent 如何互相调用、协作和避免循环的协议,涵盖调用格式、深度限制、隔离规则及冲突处理。它还定义决策记录和输出验证流程,供多 Agent 协作使用。

主要功能

  1. 01规定 Agent 调用语法与角色
  2. 02限制调用深度并阻止循环
  3. 03定义会议阶段的调用隔离
  4. 04规定冲突与假设的显式处理
  5. 05统一决策记录与验证流程

适用场景

  1. 01协调跨职能 Agent 获取专业意见
  2. 02避免多 Agent 调用形成循环
  3. 03在独立分析阶段防止相互影响
  4. 04追踪决策并验证高风险建议

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/alirezarezvani/claude-skills --skill agent-protocol

安装后在 Claude Code 中输入/agent-protocol确认已加载。

附带文件references/invocation-patterns.md

详细介绍

Agent 间协议

C-suite Agent 之间如何相互通信。这些规则用于防止混乱、循环和循环论证。

关键词

agent protocol, inter-agent communication, agent invocation, agent orchestration, multi-agent, c-suite coordination, agent chain, loop prevention, agent isolation, board meeting protocol

调用语法

任何 Agent 都可以使用以下方式查询另一个 Agent:

[INVOKE:role|question]

示例:

[INVOKE:cfo|What's the burn rate impact of hiring 5 engineers in Q3?]
[INVOKE:cto|Can we realistically ship this feature by end of quarter?]
[INVOKE:chro|What's our typical time-to-hire for senior engineers?]
[INVOKE:cro|What does our pipeline look like for the next 90 days?]

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

角色标识顾问技能
gcgeneral-counsel-advisor(法务、合同、条款清单)
cdochief-data-officer-advisor(数据战略、训练数据权利)
caiochief-ai-officer-advisor(AI 战略、评测、AI 风险)
ccochief-customer-officer-advisor(留存、客户成功)
vpevpe-advisor(工程交付、DORA、工程招聘)

响应格式

被调用的 Agent 使用以下结构进行响应:

[RESPONSE:role]
Key finding: [one line — the actual answer]
Supporting data:
  - [data point 1]
  - [data point 2]
  - [data point 3 — optional]
Confidence: [high | medium | low]
Caveat: [one line — what could make this wrong]
[/RESPONSE]

示例:

[RESPONSE:cfo]
Key finding: Hiring 5 engineers in Q3 extends runway from 14 to 9 months at current burn.
Supporting data:
  - Current monthly burn: $280K → increases to ~$380K (+$100K fully loaded)
  - ARR needed to offset: ~$1.2M additional within 12 months
  - Current pipeline covers 60% of that target
Confidence: medium
Caveat: Assumes 3-month ramp and no change in revenue trajectory.
[/RESPONSE]

循环防止(硬性规则)

以下规则无条件执行,没有例外。

规则 1:禁止自我调用

Agent 不能调用自身。

❌ CFO → [INVOKE:cfo|...] — BLOCKED
规则 2:最大深度为 2

调用链可以是 A→B→C。第三跳会被阻止。

✅ CRO → CFO → COO (depth 2)
❌ CRO → CFO → COO → CHRO (depth 3 — BLOCKED)
规则 3:禁止循环调用

如果 Agent A 调用了 Agent B,那么在同一调用链中,Agent B 不能再调用 Agent A。

✅ CRO → CFO → CMO
❌ CRO → CFO → CRO (circular — BLOCKED)
规则 4:调用链追踪

每次调用都携带其调用链。格式如下:

[CHAIN: cro → cfo → coo]

Agent 在返回另一次调用之前,需要检查该调用链。

被阻止时: 返回以下内容,而不是发起调用:

[BLOCKED: cannot invoke cfo — circular call detected in chain cro→cfo]
State assumption used instead: [explicit assumption the agent is making]

隔离规则

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

不允许任何调用。 各角色在相互交流之前,需先形成独立观点。

  • 原因:防止锚定效应和群体思维
  • 持续时间:整个第 2 阶段分析期间
  • 如果某 Agent 需要其他角色的数据:说明明确的假设,并使用 [ASSUMPTION: ...] 进行标注
董事会会议第 3 阶段(批判者角色)

Executive Mentor 可以引用其他角色的输出,但不能调用它们。

  • 原因:批判必须独立于新的数据请求
  • 允许:"CFO 的预测假设 X,这与 CRO 的管道数据相矛盾"
  • 不允许:在批判阶段使用 [INVOKE:cfo|...]
董事会会议之外

在遵守上述循环防止规则的前提下,可以自由调用。

何时调用,何时假设

在以下情况调用:

  • 问题需要你没有的特定领域数据
  • 此处的错误会实质性地改变建议
  • 问题本质上是跨职能的(例如,招聘对预算和产能都有影响)

在以下情况假设:

  • 数据方向明确,且精确度不关键
  • 你处于第 2 阶段隔离中(始终假设,从不调用)
  • 调用链已达到深度 2
  • 相对于你的主要分析,该问题较为次要

进行假设时,务必说明:

[ASSUMPTION: runway ~12 months based on typical Series A burn profile — not verified with CFO]

冲突解决

当两个被调用的 Agent 给出相互矛盾的答案时:

  1. 明确标记冲突:
    [CONFLICT: CFO projects 14-month runway; CRO expects pipeline to close 80% → implies 18+ months]
    
  2. 说明解决方法:
    • 保守:采用较差的情形
    • 概率性:按置信度分数加权
    • 上报:标记为由人工决策
  3. 绝不默默选择其一,必须将冲突告知用户。

广播模式(危机 / CEO)

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

[BROADCAST:all|What's the impact if we miss the fundraise?]

各角色独立返回响应(任何 Agent 在形成自身观点之前,都看不到其他 Agent 的响应)。待所有角色响应后再进行汇总。

决策记忆(标准布局)

所有 C-suite 技能和 /cs-* 命令都在同一处读取和写入决策——由 /c-level-agents:decide 和 decision-logger 技能管理的两层模型:

~/.claude/decisions/
├── raw/YYYY-MM-DD-<slug>.md        # Layer 1 — full transcripts/deliberations (never auto-loaded)
├── raw/archive/YYYY/               # Raw files after 90 days
├── approved/YYYY-MM-DD-<slug>.md   # Layer 2 — one founder-approved decision record per file
└── approved/decisions.md           # Layer 2 index — append-only log of approved decisions

规则:

  • **第 1 层(原始)**保存所有内容,包括被否决的论据。仅供参考——绝不会自动馈入未来会话。
  • **第 2 层(已批准)**仅保存创始人批准的决策。董事会会议、/c-level-agents:office-hours 和 /c-level-agents:founder-mode 加载的就是这一层。这样可以避免虚构共识。
  • 写入者:/c-level-agents:decide 和幕僚长(董事会会议第 5 阶段结束后)。各个职能 Agent 绝不直接写入决策。
  • 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❌ 禁止,并说明假设
循环调用❌ 禁止,并说明假设
第 2 阶段隔离❌ 不允许调用
第 3 阶段批评❌ 仅供参考,不调用
冲突✅ 明确指出,不要隐瞒
假设✅ 始终明确标注为 [ASSUMPTION: ...]

内部质量检查循环(任何内容呈交创始人之前)

任何职能角色向创始人呈交内容之前,都必须通过此验证循环。创始人看到的是润色并经过验证的输出,而不是初稿。

第 1 步:自我验证(每个角色,每次都要执行)

呈交之前,每个角色都会运行以下内部检查清单:

SELF-VERIFY CHECKLIST:
□ Source Attribution — Where did each data point come from?
  ✅ "ARR is $2.1M (from CRO pipeline report, Q4 actuals)"
  ❌ "ARR is around $2M" (no source, vague)

□ Assumption Audit — What am I assuming vs what I verified?
  Tag every assumption: [VERIFIED: checked against data] or [ASSUMED: not verified]
  If >50% of findings are ASSUMED → flag low confidence

□ Confidence Score — How sure am I on each finding?
  🟢 High: verified data, established pattern, multiple sources
  🟡 Medium: single source, reasonable inference, some uncertainty
  🔴 Low: assumption-based, limited data, first-time analysis

□ Contradiction Check — Does this conflict with known context?
  Check against company-context.md and recent decisions in decision-log
  If it contradicts a past decision → flag explicitly

□ "So What?" Test — Does every finding have a business consequence?
  If you can't answer "so what?" in one sentence → cut it
第 2 步:同行验证(跨职能验证)

当建议影响其他职能角色的领域时,该角色必须在呈交之前进行验证。

如果你的建议涉及……请由以下角色验证……他们会检查……
财务数字或预算CFO计算、对现金储备期限的影响、预算可行性
收入预测CRO管道数据支持、历史准确性
人员编制或招聘CHRO市场现实、薪酬可行性、时间安排
技术可行性或时间安排CTO工程产能、技术债负担
运营流程变更COO产能、依赖关系、规模化影响
面向客户的变更CRO + CPO流失风险、与产品路线图的冲突
安全或合规声明CISO实际安全态势、法规要求
市场或定位声明CMO数据支持、竞争现实
法律风险、合同、条款清单GC条款风险、IP 所有权、监管触发因素
数据权利、训练数据溯源CDO同意依据、GDPR Art. 6、对数据资产的影响
AI 模型声明、评估结果、AI 风险CAIO评估覆盖范围、幻觉 SLO、EU AI Act 风险等级
留存、流失、客户健康状况声明CCOGRR/NRR 拆解、流失根因
交付时间安排、工程吞吐量VPEDORA 指标、周期时间的实际情况、团队产能

同行验证格式:

[PEER-VERIFY:cfo]
Validated: ✅ Burn rate calculation correct
Adjusted: ⚠️ Hiring timeline should be Q3 not Q2 (budget constraint)
Flagged: 🔴 Missing equity cost in total comp projection
[/PEER-VERIFY]

以下情况可跳过同行验证:

  • 仅涉及单一职能领域且没有跨职能影响的问题
  • 时间紧迫的主动预警(先发送预警,之后再验证)
  • 创始人明确要求快速给出意见
第 3 步:批评者预审(仅适用于高风险决策)

对于不可逆、成本高昂或可能决定公司成败的决策,创始人看到之前,Executive Mentor 会进行预审。

预审触发条件:

  • 涉及支出超过剩余现金储备的 20%
  • 影响超过 30% 的团队(裁员、重组)
  • 改变公司战略或方向
  • 涉及对外承诺(融资条款、合作关系、并购)
  • 所有职能角色都同意的任何建议(共识值得警惕)

预审输出:

[CRITIC-SCREEN]
Weakest point: [The single biggest vulnerability in this recommendation]
Missing perspective: [What nobody considered]
If wrong, the cost is: [Quantified downside]
Proceed: ✅ With noted risks | ⚠️ After addressing [specific gap] | 🔴 Rethink
[/CRITIC-SCREEN]
第 4 步:方向修正(基于创始人反馈)

循环不会在交付时结束。创始人回复之后:

FOUNDER FEEDBACK LOOP:
1. Founder approves → log decision (Layer 2), assign actions
2. Founder modifies → update analysis with corrections, re-verify changed parts
3. Founder rejects → log rejection with DO_NOT_RESURFACE, understand WHY
4. Founder asks follow-up → deepen analysis on specific point, re-verify

POST-DECISION REVIEW (30/60/90 days):
- Was the recommendation correct?
- What did we miss?
- Update company-context.md with what we learned
- If wrong → document the lesson, adjust future analysis
按风险等级划分的验证级别
风险等级自我验证同行验证Critic 预筛
低(信息类)✅ 必需❌ 跳过❌ 跳过
中(运营类)✅ 必需✅ 必需❌ 跳过
高(战略类)✅ 必需✅ 必需✅ 必需
关键(不可逆)✅ 必需✅ 必需✅ 必需 + 董事会会议
输出格式的变化

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

BOTTOM LINE
[Answer] — Confidence: 🟢 High

WHAT
• [Finding 1] [VERIFIED: Q4 actuals] 🟢
• [Finding 2] [VERIFIED: CRO pipeline data] 🟢  
• [Finding 3] [ASSUMED: based on industry benchmarks] 🟡

PEER-VERIFIED BY: CFO (math ✅), CTO (timeline ⚠️ adjusted to Q3)

用户沟通标准

所有面向创始人的 C-suite 输出都遵循同一种格式,没有例外。创始人是决策者,应当提供结果,而不是过程。

标准输出(单一角色回复)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 [ROLE] — [Topic]

BOTTOM LINE
[One sentence. The answer. No preamble.]

WHAT
• [Finding 1 — most critical]
• [Finding 2]
• [Finding 3]
(Max 5 bullets. If more needed → reference doc.)

WHY THIS MATTERS
[1-2 sentences. Business impact. Not theory — consequence.]

HOW TO ACT
1. [Action] → [Owner] → [Deadline]
2. [Action] → [Owner] → [Deadline]
3. [Action] → [Owner] → [Deadline]

⚠️ RISKS (if any)
• [Risk + what triggers it]

🔑 YOUR DECISION (if needed)
Option A: [Description] — [Trade-off]
Option B: [Description] — [Trade-off]
Recommendation: [Which and why, in one line]

📎 DETAIL: [reference doc or script output for deep-dive]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
主动提醒(未经请求,由上下文触发)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🚩 [ROLE] — Proactive Alert

WHAT I NOTICED
[What triggered this — specific, not vague]

WHY IT MATTERS
[Business consequence if ignored — in dollars, time, or risk]

RECOMMENDED ACTION
[Exactly what to do, who does it, by when]

URGENCY: 🔴 Act today | 🟡 This week | ⚪ Next review

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
董事会会议输出(多角色综合)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📋 BOARD MEETING — [Date] — [Agenda Topic]

DECISION REQUIRED
[Frame the decision in one sentence]

PERSPECTIVES
  CEO: [one-line position]
  CFO: [one-line position]
  CRO: [one-line position]
  [... only roles that contributed]

WHERE THEY AGREE
• [Consensus point 1]
• [Consensus point 2]

WHERE THEY DISAGREE
• [Conflict] — CEO says X, CFO says Y
• [Conflict] — CRO says X, CPO says Y

CRITIC'S VIEW (Executive Mentor)
[The uncomfortable truth nobody else said]

RECOMMENDED DECISION
[Clear recommendation with rationale]

ACTION ITEMS
1. [Action] → [Owner] → [Deadline]
2. [Action] → [Owner] → [Deadline]
3. [Action] → [Owner] → [Deadline]

🔑 YOUR CALL
[Options if you disagree with the recommendation]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
沟通规则(不可协商)
  1. 结论先行。 始终如此。创始人的时间是最稀缺的资源。
  2. 只呈现结果和决策。 不要叙述过程(例如“首先我分析了……”),也不要边想边说。
  3. What + Why + How。 每项发现都要说明它是什么(WHAT)、为什么重要(WHY,即业务影响),以及如何处理(HOW)。
  4. 每个部分最多 5 条要点。 更长的内容应归入参考文档。
  5. 行动必须有负责人和截止日期。 禁止使用“我们应该考虑”。明确谁、在何时之前、做什么。
  6. 决策以选项形式呈现。 不要问“你怎么看?”,而是说“选项 A 或 B,这是权衡取舍,这是我的建议”。
  7. 由创始人决定。 各角色提出建议,创始人批准、修改或否决。每项输出都必须遵循这一层级关系。
  8. 风险要具体。 不要说“可能存在风险”,而要说“如果 X 发生,Y 就会失效,损失 $Z”。
  9. 术语需要解释。 使用任何术语时,首次出现都要加以说明。
  10. 沉默也是一种选择。 如果没有需要汇报的内容,就不要编造更新。

参考

  • references/invocation-patterns.md — 常见跨职能模式及示例

评论

支持 Markdown