两个 AI Agent 互相调用是什么体验？Kiro + OpenClaw 双协议实战，架构评审从 2 天干到 15 分钟

你有没有想过，让两个 AI Agent 互相调用、互相委托会发生什么？

上周我用 Kiro + OpenClaw 帮金融客户做 Oracle 迁移评审，从飞书收到需求到 Well-Architected 报告发回去，15 分钟。以前这活儿至少两天。

这不是什么黑科技，核心就是两条协议——MCP 和 ACP——让两个 Agent 各干擅长的事。今天把这套玩法拆给你看。

先搞清楚：这两个 Agent 分别干嘛

Kiro 是亚马逊云科技推出的 AI Agent，擅长代码生成、架构设计、Spec 驱动开发。你可以理解成一个很强的"大脑"。

OpenClaw 是开源 Agent 运行时，擅长消息处理、定时任务、设备揧制、多平台集成。相当于"手脚"——能触达外部世界。

一个能想，一个能干。问题是怎么让它们高效配合？

双通道架构：MCP + ACP

MCP：Kiro → OpenClaw

MCP（Model Context Protocol）是标准化的工具调用协议。Kiro 通过它调用 OpenClaw 暴露的工具集。

配置很简单：

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

配完 Kiro 拿到 7 个 MCP Tools。其中 openclaw_chat 是个"万能入口"——通过自然语言，Kiro 能让 OpenClaw 干它内部 40+ 种事情。发飞书、读文档、搜数据、控设备，全走这一个入口。

说实话我一开始觉得 7 个 tool 也太少了。后来理解了——openclaw_chat 本质是个自然语言网关，tool 数量少反而看 token。这设计挺聪明。

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

ACP：OpenClaw → Kiro

反过来，OpenClaw 通过 ACP（Agent Communication Protocol）把复杂任务委派给 Kiro。JSON-RPC 2.0 over stdio，异步有状态。

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"},
})

两条通道互补：

维度	MCP（Kiro→OpenClaw）	ACP（OpenClaw→Kiro）
模式	同步/异步工具调用	异步任务委派
延迟	<5s / 分钟级	30s-5min
价值	Kiro 获得"手"	OpenClaw 获得"脑"

MCP 给 Agent 装手，ACP 给 Agent 装脑。 这就是双协议的意义。

案例一：架构评审自动化（2 天→15 分钟）

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

流程：

1. 客户在飞书发迁移需求
2. OpenClaw 自动提取关键信息（架构/合规/SLA）
3. ACP 委派 Kiro 做评审
4. Kiro 生成：多 AZ 架构图 + Well-Architected 评估 + AWS CDK 模板
5. 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 },
      ],
    });

    const db = new DatabaseCluster(this, 'AuroraCluster', {
      engine: rds.DatabaseClusterEngine.auroraPostgres({
        version: rds.AuroraPostgresEngineVersion.VER_15_4,
      }),
      instances: 2, vpc,
    });

    const cluster = new Cluster(this, 'EksCluster', {
      version: eks.KubernetesVersion.V1_29,
      vpc, defaultCapacity: 3,
    });
  }
}

Well-Architected 六大支柱打分：安全性 92、可靠性 88、成本优化 85、可持续性 81、性能效率 76、卓越运营 72。

踩坑记录：ACP 握手第一次跑的时候超时了。查了半天发现 kiro-cli acp 冷启动要 8-10 秒，在 OpenClaw 侧加了预热——启动时先跑一次空握手。后面就丝滑了。

案例二：游戏运维智能响应（30 分→3 分钟）

DAU 500 万的 MMO，凌晨两点 CPU 87%，14 个 Pod Pending，WebSocket 断连 1247 次/分钟。

指标	数值	状态
CPU 利用率	87.3%	🔴 严重
Pod Pending	14	🔴 严重
WebSocket 断连	1,247/min	🟡 警告
在线玩家	2.3M	🟢 正常

自动响应流程：

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

3 分钟恢复，零人工。MTTR 降 90%。

这里让我比较惊喜的是 Kiro 通过 ACP 做的根因分析。不是简单搜日志关键词，而是结合 X-Ray 调用链定位到具体服务版本的内存泄漏。人工做这事也要十几分钟。

案例三：跨平台游戏数据日报

每天 9 点自动出日报，覆盖 DAU/收入/留存/新增/付费转化。

数据来源：GameAnalytics + Adjust + App Store Connect + Amazon Athena。

流程：Cron 触发 → 拉多平台数据 → ACP 委派 Kiro 清洗 + 异常检测 → HTML 可视化日报 → 多通道分发。

Kiro 在这里干的是异常检测。DAU 波动 >15% 自动标红，给出可能原因。以前运营同学每天花 40 分钟手动拉数据做表格，现在到工位直接看报告。

案例四：Spec 驱动异步编码（17 分钟交付）

这个案例的思路让我眼前一亮：Kiro 当架构师，OpenClaw 当程序员。

Kiro 侧（Spec 模式）：

.kiro/specs/
├── requirements.md    # 需求文档
├── design.md          # 技术设计
├── tasks.md           # 8 个 Task
├── test-criteria.md   # 测试用例
└── architecture.mmd   # 架构图

Kiro → OpenClaw（MCP 异步调用）：

Tool: openclaw_chat_async
{
  "message": "从 s3://project-specs/proj-xxx/ 下载 Spec 文件，逐 Task 编码...",
  "session_id": "kiro-dev-proj-xxx"
}
// → { "task_id": "task_a1b2c3d4", "status": "accepted" }

OpenClaw 编码完成后：

{
  "status": "completed",
  "result": {
    "repo_url": "https://github.com/org/project-xxx",
    "commits": 8, "files_created": 24,
    "test_coverage": "87%", "test_passed": "42/42"
  },
  "duration": "16m 52s"
}

24 个文件，87% 覆盖率，42 个测试全过。17 分钟。

踩的坑：OpenClaw 子智能体并发执行 Task 时，Task 4 依赖 Task 3 的输出，但先跑完了。import 了个还没生成的模块直接报错。后来在 tasks.md 加了 depends_on 字段解决。教训：异步编码的任务依赖一定要显式声明。

为什么必须是两个协议？

协议	定位	类比
MCP	工具层	API Gateway
ACP	协作层	消息队列 + 工作流引擎

MCP 解决"怎么调用工具"，ACP 解决"怎么委托任务"。一个是同步 RPC 的思路，一个是异步消息的思路。场景不同，不能混。

从技术演进看：Phase 1（人→AI 工具）→ Phase 2（Agent↔Agent）→ Phase 3（多 Agent 自组织）。Kiro + OpenClaw 是 Phase 2 的落地实践。

总结

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

跑完四个案例，我的判断：双协议互补是 Agent 协作的正确姿势。MCP 管"干活"，ACP 管"想事"。openclaw_chat 万能入口的设计很聪明，看 token。异步是重任务的刚需。踩坑主要在两个 Agent 的衔接处——超时、依赖、状态同步要细扣。

Agent 协作还在早期。但这个方向，感觉对了。

资源链接

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