大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



两个 AI Agent 怎么互相调用？这个问题困扰了我一阵子。直到把 Kiro 和 OpenClaw 用 MCP + ACP 两条协议串起来，跑通了四个生产级场景，我才觉得这事儿靠谱。

这篇文章从协议层面深入拆解双向协作架构，重点讲技术细节和踩坑。

Kiro（亚马逊云科技 AI Agent）：代码生成、架构设计、Spec 驱动开发。定位是"大脑"。

OpenClaw（开源 Agent 运行时）：消息处理、定时任务、设备控制、多平台集成。定位是"手脚"。

两条协议各管一个方向：

• MCP（Kiro → OpenClaw）：工具调用协议，Kiro 把 OpenClaw 当工具使
• ACP（OpenClaw → Kiro）：任务委派协议，OpenClaw 把重活儿丢给 Kiro

{ "mcpServers": { "openclaw": { "command": "npx", "args": ["-y", "openclaw-mcp@latest"], "env": { "OPENCLAW_GATEWAY": "https://gw.openclaw.ai", "OPENCLAW_TOKEN": "${OPENCLAW_TOKEN}" }, "transportType": "stdio" } } } 

传输层走 stdio，MCP Server 跑在本地。Kiro 和 OpenClaw MCP Server 之间是标准的 JSON-RPC 通信。

OpenClaw MCP Server（v1.3.0）暴露 7 个工具：

关键设计：openclaw_chat 是个"万能入口"。OpenClaw 内部有 40+ 工具能力，但不逐个暴露为 MCP tool，而是通过自然语言路由。

为什么这么设计？

MCP tool 描述会占 token。7 个 tool 的 token 开销远小于 40+ 个。而 openclaw_chat 本质上是个自然语言网关——Kiro 发一句"帮我把报告发到飞书群"，OpenClaw 内部自行路由到消息发送工具。

这个设计在 tool 数量和能力覆盖之间找到了平衡点。

同步工具（openclaw_chat）适合轻量操作：发消息、查状态、读数据。延迟 <5s。

异步工具（openclaw_chat_async + openclaw_task_status）适合重任务：编码、报告生成。提交后立即返回 task_id，后续轮询。

ACP 基于 JSON-RPC 2.0，传输层也是 stdio。通过 kiro-cli acp 启动常驻子进程。

self._proc = subprocess.Popen( ["kiro-cli", "acp"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE ) self._send_request("initialize", { "protocolVersion": 1, "clientCapabilities": { "fs": {"readTextFile": True, "writeTextFile": True}, "terminal": True }, "clientInfo": {"name": "kiro-api-bridge", "version": "1.0.0"}, }) 

握手时声明客户端能力：文件读写 + 终端。Kiro 据此决定能接受什么类型的任务。

ACP 是有状态的。任务有明确的生命周期：提交 → 处理中 → 完成/失败。支持进度查询和超时控制。

与 MCP 的本质区别：MCP 是"调用工具"，ACP 是"委托同事"。一个是函数调用的思路，一个是消息传递的思路。

ACP 侧用指数退避 + 降级策略。比如 Kiro 侧超时，不是直接报错，而是降级到更简单的任务描述重试。

场景：金融客户迁移 Oracle RAC + WebLogic + F5 → Amazon Aurora PostgreSQL + Amazon EKS + ALB。

流程：

1. 飞书收到需求 → OpenClaw 提取关键信息（架构/合规等保三级/SLA 99.95%）
2. ACP 委派 Kiro
3. Kiro 生成三份交付物：架构图 + Well-Architected 评估 + CDK 模板
4. OpenClaw 发回飞书

CDK 模板：

export class FinanceInfraStack extends cdk.Stack { constructor(scope: cdk.App, id: string) { super(scope, id); const vpc = new Vpc(this, 'FinanceVpc', { maxAzs: 3, natGateways: 2, subnetConfiguration: [ { name: 'Public', subnetType: SubnetType.PUBLIC }, { name: 'Private', subnetType: SubnetType.PRIVATE_WITH_EGRESS }, { name: 'Isolated', subnetType: SubnetType.PRIVATE_ISOLATED }, ], }); new DatabaseCluster(this, 'AuroraCluster', { engine: rds.DatabaseClusterEngine.auroraPostgres({ version: rds.AuroraPostgresEngineVersion.VER_15_4, }), instances: 2, vpc, }); new Cluster(this, 'EksCluster', { version: eks.KubernetesVersion.V1_29, vpc, defaultCapacity: 3, }); } } 

Well-Architected 评估：安全性 92 / 可靠性 88 / 成本优化 85 / 可持续性 81 / 性能效率 76 / 卓越运营 72。

15 分钟完成，原需 2 天。

踩坑：kiro-cli acp 冷启动 8-10 秒导致握手超时。加了预热机制——OpenClaw 启动时先跑一次空握手。

场景：DAU 500 万 MMO，凌晨 CPU 87%，14 Pod Pending。

流程：

1. OpenClaw 检测告警 → 推飞书运维群
2. ACP 委派 Kiro 分析 Amazon CloudWatch Logs + AWS X-Ray
3. 根因：匹配服务 v2.3.1 内存泄漏，heap +340MB/h
4. 自动修复：Amazon EKS 3→8，滚动重启，生成修复 PR
5. 生成 AWS CloudFormation 变更集 + RCA 报告
6. 飞书/Discord/PagerDuty 多通道推送

3 分钟恢复，MTTR 降 90%。

技术亮点：Kiro 通过 ACP 接收到诊断任务后，不是简单搜日志，而是结合 AWS X-Ray 调用链做深度根因分析。人工做这个也要十几分钟。

这个场景技术上不复杂，但实用价值很高。

背景：游戏发行团队需要每天 9 点看到昨日运营数据。数据分散在 GameAnalytics、Adjust、App Store Connect、Amazon Athena 四个平台，口径不同，时区不同。运营同学每天手动拉数据做表格，40 分钟起步。

流程：OpenClaw Cron 每天 9 点触发 → 自动拉取四平台数据 → ACP 委派 Kiro 做数据清洗（对齐时区和口径）+ 异常检测（DAU 波动 >15% 标红并分析原因）→ 生成 HTML 可视化日报 → 飞书/邮件/钉钉多通道分发。

Kiro 的异常检测不是简单的阈值告警，而是结合历史趋势和事件关联（比如"DAU 下降 18%，疑似与昨日版本更新导致的登录异常相关"）。

结果：全自动，零人工。运营到工位直接看日报。

核心：Kiro 写 Spec（需求→设计→Task），OpenClaw 编码。

Spec 结构：

.kiro/specs/ ├── requirements.md # FR-001~003 + NFR-001 ├── design.md # Next.js 14 + tRPC + Prisma + PostgreSQL ├── tasks.md # 8 个 Task，含依赖关系 ├── test-criteria.md └── architecture.mmd 

异步提交：

Tool: openclaw_chat_async { "message": "从 S3 下载 Spec，逐 Task 编码..." } // → { "task_id": "task_a1b2c3d4", "status": "accepted" } 

完成：

{ "status": "completed", "result": { "commits": 8, "files_created": 24, "test_coverage": "87%", "test_passed": "42/42" }, "duration": "16m 52s" } 

踩坑：Task 间有依赖但并发执行，Task 4 先完成，import 了 Task 3 还没生成的模块。修复方案：tasks.md 里加 depends_on 字段。

两个协议解决不同层面的问题，不能互相替代。MCP 管工具调用，ACP 管任务协作。

技术演进路径：Phase 1（人→AI 工具）→ Phase 2（Agent↔Agent，MCP+ACP）→ Phase 3（多 Agent 自组织）。

Kiro + OpenClaw 是 Phase 2 的落地实践。双协议互补、万能入口设计、异步任务委派，这三点是我认为这个架构可行的核心原因。

坑主要在 Agent 衔接处：冷启动超时、任务依赖、状态同步。但这些都是工程问题，有解。

几点具体建议：

1. ACP 子进程必须预热。冷启动 8-10 秒在生产环境不可接受，启动时跑一次空握手。
2. 异步 Task 依赖要显式声明。别指望子智能体自己推断依赖关系。
3. 降级策略不能省。Kiro 侧超时了，先出简化版本，不要直接报错。指数退避 + 降级比简单重试靠谱。
4. 万能入口模式值得推广。不止 Agent 场景，任何 MCP Server 都可以考虑自然语言路由替代大量 tool 枚举。

Agent 协作还在早期阶段。但从这四个场景的效果看，双协议分层的架构经受住了验证。接下来值得关注：更多类型 Agent 接入协作网络、协议标准化推动跨平台互操作。

• Kiro 官网 | Kiro ACP 文档
• OpenClaw GitHub | OpenClaw 文档
• OpenClaw MCP Server
• MCP 规范
• 亚马逊云科技官方博客原文