Kiro + OpenClaw 双协议深度解析：MCP 工具调用与 ACP 异步委派的架构设计及四个实战案例

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

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

架构总览

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

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

两条协议各管一个方向：

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

MCP 通道技术细节

配置

{
  "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 通信。

Tool 设计

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

工具名	类型	说明
openclaw_chat	同步	自然语言万能入口
openclaw_status	同步	Gateway 状态
openclaw_instances	同步	实例列表
openclaw_chat_async	异步	异步提交任务
openclaw_task_status	异步	查询任务进度
openclaw_task_list	异步	任务列表

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

为什么这么设计？

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

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

同步 vs 异步

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

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

ACP 通道技术细节

协议层

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%，疑似与昨日版本更新导致的登录异常相关"）。

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

实战案例四：Spec 驱动异步编码

核心：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
定位	工具层	协作层
类比	API Gateway	消息队列 + 工作流
状态	无状态（同步）/ 有状态（异步）	有状态
延迟	<5s / 分钟级	30s-5min
错误策略	简单重试	指数退避 + 降级

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

效果汇总

案例	效果
架构评审	2 天 → 15 分钟
智能运维	30 分 → 3 分钟
数据日报	全自动
异步编码	17 分钟

写在后面

技术演进路径：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 规范
• 亚马逊云科技官方博客原文