使用 Kiro CLI 和 Agent Client Protocol 构建飞书 AI 聊天机器人

摘要：如何将 Kiro CLI 变成通用 Agent 后端，并用不到 1000 行 Rust 代码构建一个飞书聊天机器人。

01 一、引言：每个团队都想要 AI Agent，但从零构建太难了

02 二、什么是 Agent Client Protocol (ACP)？

03 三、为什么用 Kiro CLI 做 Agent 后端

04 四、深入解析：acp-link 如何桥接飞书与 Kiro CLI

05 五、实际演示

06 六、结语

一、引言：每个团队都想要 AI Agent，但从零构建太难了

你大概见过这样的场景：团队想在即时通讯平台上搭建一个 AI 聊天机器人。刚开始梳理需求——LLM 集成、流式响应、工具调用、Skill 支持、会话管理、上下文窗口、成本评估…还没写一行业务逻辑，工作量就已经堆积如山。

如果能跳过这些，直接复用一个成熟的 Agent 运行时作为后端呢？

这正是我们做的事情。我们构建了 acp-link——一个将飞书与 Kiro CLI 通过 Agent Client Protocol (ACP) 连接的桥接服务。最终效果：一个具备流式响应、工具调用、文件处理和多轮对话能力的 AI 聊天机器人，全部由 Kiro 的 Agent 运行时驱动。

二、什么是 Agent Client Protocol (ACP)？

Agent Client Protocol 是一个开放协议，用于 Agent 客户端（如 IDE）与 Agent 服务端（如 Kiro CLI）之间的通信。可以把它理解为”与 AI Agent 对话”的标准化语言。

ACP 定义了一套结构化的交互方式：

创建和管理会话（Session）——每个对话拥有独立的 Session 和上下文
发送富内容 Prompt——文本、图片（Base64）、文件引用、资源链接
接收流式响应——Agent 实时返回文本片段、工具调用通知和结构化内容块
处理工具调用——Agent 可以通过 MCP 调用工具，并通过协议报告执行状态

该协议运行在 stdio（标准输入/输出）之上，非常轻量且易于集成。你只需启动一个 Kiro CLI 进程，通过 stdin/stdout 交换 JSON 消息，就拥有了一个功能完整的 Agent。

ACP通信示意图

关键在于：ACP 不关心对端是谁。协议本身是客户端无关的。任何能启动进程并交换 JSON 消息的应用都可以成为 ACP 客户端。

三、为什么用 Kiro CLI 做 Agent 后端

Kiro CLI它是 Kiro IDE 的命令行版本，他不仅仅可以用于Coding，还可以将其作为通用Agent使用。真正让它作为通用 Agent 运行时脱颖而出的是以下能力：

3.1 Custom Agent（自定义 Agent）

Kiro CLI 支持 Custom Agent——你可以通过配置定义专属的 Agent 行为，包括人设、能力范围和约束条件。想要一个遵循团队代码规范的 Code Review Agent？一个围绕产品主题的聊天机器人？一个只在安全边界内操作的运维 Agent？Custom Agent 都能实现。更多示例可参考 Agent Examples。

创建 Custom Agent 的详细步骤请参考 Creating Custom Agents。这里以创建一个 Code Review Agent 为例，只需在 ~/.kiro/agents/ 目录下创建一个 JSON 配置文件：

// ~/.kiro/agents/codereview.json
{
  "name": "code-review-agent",
  "description": "Specialized custom agent for code review and quality analysis",
  "prompt": "You are a code review specialist focused on quality, security, and best practices",
  "tools": ["read", "shell"],
  "allowedTools": ["read", "shell"],
  "toolsSettings": {
    "shell": {
      "allowedCommands": [
        "grep",
        "find",
        "wc",
        "head",
        "tail",
        "cat",
        "diff",
        "git diff",
        "git log",
        "cargo"
      ]
    }
  },
  "resources": ["skill://~/.kiro/skills/rust-code-review/SKILL.md"],
  "hooks": {
    "agentSpawn": [
      {
        "command": "git diff --name-only HEAD~1",
        "timeout_ms": 5000,
        "max_output_size": 2048
      }
    ]
  }
}

这个配置做了几件关键的事情：

prompt——定义 Agent 的人设，聚焦于代码质量、安全和最佳实践
toolsSettings——通过白名单限制 Shell 命令，确保 Agent 只能执行代码审查相关的操作（如git diff、grep），不会误触危险命令
resources——引用一个 Skill 文件，将团队的代码审查规范以SKill的方式注入 Agent 上下文，让它按照你的标准评审代码
hooks.agentSpawn——Agent 启动时自动执行git diff，将最近的变更文件列表注入上下文，Agent 立即知道该审查哪些文件

创建完成后，只需执行kiro-cli acp --agent code-review-agent即可将 Custom Agent 启动在 ACP 模式下。

3.2 内置工具与 MCP 支持

Kiro CLI 内置了shell、read、write、grep、glob、web_fetch、web_search等常用工具，开箱即用。
除此之外，Kiro CLI 原生支持 Model Context Protocol (MCP)，这意味着你的 Agent 可以直接使用任何兼容 MCP 的工具服务。需要查询数据库？检索文档？调用外部 API？只需为 Kiro 配置对应的 MCP Server 即可。

3.3 Skill 与 Sub-agent

Kiro CLI内置了 Skill 支持——可复用的 Prompt 模板，支持组合和参数化，为 Agent 提供了丰富的扩展能力。

配合 Sub-agent（Agent 为子任务生成专属子 Agent）机制，你无需额外开发就拥有了一套成熟的任务编排层。

3.4 Session 管理

每个对话自动获得一个持久化 Session。Kiro CLI 在内部处理上下文累积、消息历史和 Token 管理。你的应用只需维护”哪个 Session ID 对应哪个IM用户对话”的映射关系即可。

3.5 成本优势

规模化运行 AI Agent 非常昂贵。直接调用 Claude 等前沿模型的 API，费用增长很快——尤其是 Agent 使用工具时，每次交互的 API 调用次数会成倍增加。再加上流式传输、重试和上下文管理的开销，账单可能令人咋舌。

Kiro CLI 采用基于 Credit 的订阅模式。对于已有 Kiro 许可证的团队，使用 Kiro CLI 作为 Agent 运行时意味着：

- 可预测的成本——Credit 定价 vs. 按 Token 计费的 API
- 更低的单次交互成本——Kiro 的打包定价在 Agent 工作负载下远低于直接调用 Claude API
- 无需管理 API Key——Kiro 处理认证

因此，用 Kiro-CLI 做 Agent 后端，你将获得全套 Agent 基础能力：

能力	自行构建	使用 Kiro CLI
LLM 集成	自定义 API 客户端、重试逻辑、流式解析器	内置
工具调用 (MCP)	实现 MCP 客户端	内置
Session 管理	自定义持久化层	内置
Sub-agent	自定义编排逻辑	内置
Skill/Prompt	自定义模板系统	内置
成本优化	Token 计数、缓存	内部处理

这不仅是节省开发时间——更关键的是不需要长期维护这些基础设施。对于中小规模的 AI Agent 应用，这是非常显著的优势。

3.6 IDE 之外的应用场景

ACP + Kiro CLI + MCP 的组合在传统 IDE 集成之外打开了广阔的可能性：

企业聊天机器人——接入飞书、Slack、钉钉或任何即时通讯平台。Agent 处理对话，你只需桥接消息。
Code Review Agent——对接 Git 平台的 Webhook，将 PR 发送给 Agent，获取结构化的审查反馈。
DevOps 助手——为 Agent 配备基础设施相关的 MCP 工具（AWS、Kubernetes、监控），让团队通过自然语言查询和操作。
知识库问答——将 MCP 指向你的文档或数据库，Agent 即成为领域专家。
自动化工作流——通过 CI/CD 事件、定时任务或其他系统事件触发 Agent 行为。

模式始终一致：你的应用处理领域特定的 I/O（即时通讯平台、Git Webhook、API Endpoint），Kiro CLI 处理 AI Agent 逻辑。

四、深入解析：acp-link 如何桥接飞书与 Kiro CLI

下面我们详细走一遍 acp-link 的架构，看看它实际是如何运作的。你也可以参考这个思路来实现自己的 Agent 应用的交互。

4.1 架构概览

acp-link架构图

4.2 数据流概览

acp-link 的核心工作可以概括为三步：接收 → 转发 → 回传。

1. 接收飞书消息——通过 WebSocket 长连接监听飞书事件，解析后发送给核心服务

2. 转发到 Kiro CLI——将飞书的 Thread（话题）映射到 ACP Session。首次对话自动创建 Session，后续消息增量发送。相比 OpenClaw 在飞书 IM 里需要手动/new切换上下文，基于话题的交互更能保持 Agent 上下文的干净和连贯

3. 流式回传响应——Kiro CLI 的流式输出被累积并以消息卡片的形式实时更新到飞书，工具调用状态也会同步展示（例如”正在搜索文档……”）

整个过程中，acp-link 维护了一个 Kiro CLI 进程池，通过一致性哈希将同一对话始终路由到同一个 Worker，保证 Session 上下文连续，避免频繁的 Session 载入。

4.3 配置 Agent 与飞书对接

安装完成后，在 acp-link 的config.toml中指定args = [“acp”, “—agent”, “code-review-agent”]，飞书中的对话就会由这个专属的 Code Review Agent 来处理。团队成员只需在飞书群里 @机器人即可完成 Code Review 等任务的交互。

4.4 双向集成：内嵌 MCP Server

acp-link 不仅向 Agent 转发消息——Agent 也可以反向操作飞书。通过内嵌一个MCP Server，飞书的能力被作为工具暴露给 Kiro CLI。例如，当 Agent 需要向用户发送文件时，它通过 MCP 调用feishu_send_file工具，由桥接服务在幕后处理飞书的上传 API。

这种双向设计让 Agent 成为飞书对话中的一等参与者，而不仅仅是一个文本回复器。

五、实际演示

5.1 acp-link 配置示例

以下是 acp-link 的config.toml模板配置，指定了飞书应用凭证、Kiro CLI 启动参数和 MCP Server 端口等关键选项：

log_level = "debug"

# 日志保留天数，默认 7 天
# log_retention = 7

# Session 保留天数，默认 7 天
# session_retention = 7

# 资源文件保留天数，默认 7 天
# resource_retention = 7

[feishu]
app_id = "cli_xxxxxxx"
app_secret = "xxxxxxxxx"

[kiro]
cmd = "kiro-cli"
args = ["acp", "--agent", "code-review-agent"]

# 进程池大小，通过 thread_id hash 路由实现并行处理，默认 4
# pool_size = 4

# Agent 工作目录，用作项目上下文路径；未配置时默认为 ~/.acp-link/temp/
# cwd = "/path/to/your/project"

[mcp]
# HTTP 监听端口，默认 9800
# port = 9800

配置完成后启动acp-link，飞书中的对话就会由指定的 Custom Agent 来处理。

5.2 场景一：Code Review Agent

我们为团队配置了一个专属的 Code Review Agent，团队成员在飞书话题中发送代码审查请求，Agent 自动分析项目结构并给出专业反馈。

第一步：Agent 浏览项目结构，了解代码全貌

[图4]

用户在飞书中发出请求，Agent 通过工具调用浏览项目目录结构，快速了解代码组织方式。

第二步：Agent 逐文件分析，发现潜在问题

Agent 加载配置好的 Code Review Skill，阅读关键文件，识别出代码风格、错误处理、并发安全等方面的问题，并在飞书话题中实时输出分析过程。

第三步：输出结构化的 Code Review 报告

最终，Agent 输出一份按严重等级分类的 Code Review 报告，包含具体的代码位置、问题描述和修改建议。团队成员可以在话题中继续追问，深入探讨具体问题。

5.3 场景二：通用聊天Agent

除了 Code Review，同样的架构也可以支撑通用 AI 聊天助理的功能，你可以把他作为OpenClaw的简化版替代。以下演示使用另一个 Custom Agent 在飞书中汇总 AWS 技术博客。

Kiro CLI 借助内置的web_fetch工具抓取并摘要博客内容，展示了其作为通用 Agent 的能力。

5.4 快速上手

如果你已经有一个OpenClaw，你可以让他参考这个文章和acp-link项目Github仓库链接，快速建立一个自定义Agent，运行acp-link服务，在飞书上与Agent进行交互。

对于生产环境或者需要安全的场景，你也可以参考acp-link代码仓库的README文件，快速的部署一个自定义Agent服务与飞书集成交互。

1. 配置 Kiro CLI——通过 Custom Agent 为你的场景定制 Agent 行为

2. 实现 ACP 客户端逻辑——启动 Kiro CLI 进程，建立 stdio 通信，处理 ACP 消息格式

3. 构建平台适配器——处理平台特定的认证、WebSocket/Webhook、消息格式化

4. 映射对话到 Session——将平台的 Thread/Channel 模型映射到 ACP Session ID

5. 流式回传响应——累积 Agent 输出并更新平台 UI（卡片、消息等）

6. 可选：通过 MCP/Skill 丰富 Agent 能力——让 Agent 能够调用额外的功能

acp-link 是开源的，可作为这种模式的参考实现。虽然它针对飞书，但架构可以扩展到任何即时通讯平台。

六、结语

Kiro CLI + ACP + MCP 的组合为在 IDE 之外构建 AI Agent 提供了一个强大且高性价比的基础。与其从零组装一个 Agent——LLM 客户端、工具编排、Session 管理、流式传输、错误处理——不如直接使用一个生产就绪的 Agent 运行时，将其对接到任何前端。

对于已经使用 Kiro 的团队来说，经济账非常划算：更低的单次交互成本、零基础设施维护，以及一个随 Kiro 更新不断改进的成熟 Agent。

acp-link 证明了，构建一个功能完备的 AI 聊天机器人，并不需要构建一套复杂的 AI 技术栈。有时候，最好的代码就是你不需要写的代码。

acp-link 已在 GitHub 开源，欢迎贡献代码和适配其他即时通讯平台。

➡️ 下一步行动：

相关产品：

Amazon Kiro — AI 驱动的 IDE

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客