Kollab 如何基于 Amazon Bedrock AgentCore 构建可执行、可恢复的 Agent 协作架构

在团队协作中，大模型真正卡脖子的地方往往不是“答不上来”，而是“答完后谁去按按钮”。

一个任务，白天在 Web 端推进，晚上在 Slack 或 Telegram 里追问，第二天可能还要靠 Bot 或定时任务接着跑。如果每个入口各管一套上下文，Agent 就会像个重度健忘症患者，每次都在重新认识任务。

Kollab 的核心正是解决这个断层。我们不打算把大模型硬塞进聊天框，而是将 Task、Project、Knowledge、Bot、Skills 以及工作区操作，全部拉到同一条执行链路里，让 Agent 既能读懂上下文，也能直接动手。为了撑起这条链路，Kollab 的底层组合使用了 Amazon Bedrock AgentCore、Amazon EKS、Amazon S3、Amazon DynamoDB、Amazon RDS、Amazon EC2、Amazon CloudFront 以及 Amazon CloudWatch 等一整套 AWS 服务。

这篇文章将结合 Kollab 的代码实现，聊聊这个架构要解决的实际问题、统一执行面的设计思路，以及内置的 Kollab CLI、Session Storage、LiteLLM 网关和 Bot/Skills 在其中扮演的角色。

图 1：Kollab 统一执行架构。多入口最终收敛于同一个执行面与恢复链路。

1. Kollab 定位：不仅仅是“回答”

Kollab 是一款主打团队协作与持续执行的产品。它的重点不是“生成一次漂亮的回答”，而是“围绕一个任务持续把事做完”。

对协作系统而言，最核心的上下文无外乎四点：

• 当前在哪个 Space、Project 和 Task 里？
• 挂载了哪些 Knowledge、Skills 和 MCP 能力？
• 已经产生了什么消息、Artifact 和工作区文件？
• 这次触发来自 Web、Slack、Telegram、Bot，还是自动化流？

上下文如果不统一，模型很容易退化成没有记忆的闲聊机器人。Kollab 的设计初衷，就是把这些散落的信息和执行能力收拢到一个统一的工作面，让 Agent 从“只会说”变成“接着做”。

2. 协作链路的真正痛点

把 Agent 接入团队协作，难点通常不在模型本身，而是链路太碎。

第一，入口多，但上下文不能断。用户在 Web 端开了个任务，转头在 Slack 追问，或者直接敲 CLI 看历史、改 Prompt、调 Artifact。如果换个入口就得重新加载一遍记忆，体验会非常割裂。

第二，输出绝不能只停在文本。真正耗时的是那些需要手动点开的“最后一步”：推进任务、翻历史、改 Bot 配置、更新 Memory、查 Artifact、调 Prompt，或者把现成的知识库喂给本轮执行。如果 Agent 只能口头建议，不能直接上手，协作成本根本降不下来。

第三，Runtime 必须具备恢复能力。只要 Agent 开始持续读写工作区、调用工具、串联多轮任务，它就不再是个一次性的对话框，而是个随时会被中断、又需要随时续接的执行面。Session 能不能无缝接上，Workspace 能不能找回，决定了系统的死活。

基于这些痛点，Kollab 走了一条死磕到底的路：统一入口、统一执行面、统一恢复链路。

3. 统一执行链路如何运转

在 Kollab 里，一次典型的请求流转如下：

1. 请求从 Web、Slack、Telegram 或 Bot 进来后，Kollab Server 率先补齐 User、Space、Project、Task 和 Bot Binding 等业务上下文。
2. 进入 skills-server，系统顺手把 project_context、knowledge_base_config、mcp_server_ids、allowed_cli_commands 和模型配置全装配好。
3. 真正干活时，请求被丢进 Amazon Bedrock AgentCore 对应的 Runtime。注意，这里跑的可不是简单的 API 调用脚本，而是一个基于 Claude Agent SDK 的完整宿主环境。
4. Runtime 运行期间，既能调用 Skills，也能直接敲内置的 Kollab CLI，对着 Task、Artifact、Bot、Memory 和工作区资源一顿操作。
5. 路由分发：Bedrock 体系内的请求直接走原生模型；其他 Provider 的请求则统一交给 LiteLLM 网关处理。
6. 数据落盘：运行中产生的 Transcript、Workspace 文件和 Artifact 持续往 Amazon S3 里写；消息、Skills 和 MCP 等高频结构化数据丢给 DynamoDB；而 Space、Project、Task 等核心主数据则稳稳扎在 Amazon RDS 里。

这条链路的灵魂，在于“九九归一”。不管你从哪进来的，最后都落到同一个执行面。对 Kollab 来说，压根没有多套 Agent，只有同一套系统的不同触发开关。

4. Agent Runtime：将对话、工作区与技能融为一体

Kollab 把核心 Runtime 放在了 Amazon Bedrock AgentCore 上。在我们看来，Runtime 不是单纯的推理黑盒，而是干活的现场。

它需要同时 handle 三件事：

• 当前对话的 Session Transcript
• 工作区里的文件和 Artifact
• 任务能调用的 Skills、CLI 和工具

把这三者揉进同一个执行面，Agent 才清楚“下一步该干嘛”。Kollab 拒绝把任务拆成“前台聊天，后台跑工作流”的两截设计，而是让 Runtime 直接接管工作空间。这样一来，上下文、权限和状态就再也不会半路断线了。

5. Session Storage + S3：低成本的“死灰复燃”

为了保证协作不断档，Kollab 搞了一套“Session Storage + Amazon S3”的两阶段恢复机制。

在同一个 Runtime Session 里，AWS Session Storage 会把持久化目录直接挂到 /mnt/agent。命中缓存时，Runtime 连工作目录都不用重建，文件和状态拿来就用。Stop / Resume 的开销极低，Warm Session 的体验几乎就是“上次聊到哪了，咱继续”。

同时，Amazon S3 作为 Write-through 备份和跨周期的终极兜底。即便 Runtime 因为闲置、缩容或宕机被干掉，系统照样能从 S3 里把状态捞回来。

图 2：Kollab 的两阶段恢复。优先恢复 Transcript 解锁 resume，剩余文件后台默默拉回。

目前的恢复策略分两步走：

1. Phase 1：优先抢救 .claude-sessions JSONL
2. Phase 2：后台静默拉回 Workspace 文件和 Artifact

这里的逻辑很简单：对于 Agent，能随时接上远比每次从头算起重要。当任务跨越多个轮次和文件时，它已经是持续执行，而不是在闲聊了。

6. 内置 Kollab CLI：让 Agent 真正“动手”

Kollab Runtime 内部塞了个 Kollab CLI，这算是整个架构里最骚的操作之一。

没这玩意儿，模型只能逼逼赖赖告诉你“该怎么做”。有了 CLI，Agent 就能在工作区里直接撸起袖子干，比如：

• 顺着 Task，扒历史、改 Prompt
• 翻阅 Artifact 和 Workspace 文件
• 随手更新 Bot、Skill、Memory 或 Timer
• 在既有知识库的范围内深挖、洗稿或修改

那些原本需要人肉点界面的活，Kollab 全给你包了。这不是“聊天变更聪明了”，而是 Agent 终于能帮你把最后一步给走完了。

图 3：Runtime 内置 Kollab CLI。对话中的需求，Agent 顺手就能落到具体资源上。

附带的红利是，它能跟 Bot 权限模型完美契合。Bot Runtime 可以通过 allowed_cli_commands 把 CLI 的权限死死圈在特定命令里。Kollab 给的不是个裸奔的终端，而是一把带着电子脚镣的干活工具。

7. LiteLLM 网关：Bedrock 之外的任意门

Kollab 没打算在一棵树上吊死。

Bedrock 的模型走专线；GLM、Kimi 这种非 Bedrock 的，统一交给 LiteLLM 网关去适配。这个网关目前独立扛在东京区的 Amazon EC2 上，挂着 llm.kollab.im 和 llm-test.kollab.im 两个域名接客。

好处显而易见：

• 路由和主业务解耦，换个 Provider 也就是改改配置的事。
• Runtime 侧接口稳如老狗，不用给每个 Provider 单独写一套适配逻辑。

在这套架构里，LiteLLM 扮演的是模型兼容中心，而非简单的代理转发。

8. AWS 基础设施排兵布阵

盘点一下 Kollab 里各路 AWS 服务的戏份：

• Amazon Bedrock AgentCore：核心 Runtime 载体，负责会话、工具调用和真刀真枪的执行。
• Amazon EKS：扛着 server、skills-server 和前端服务，把业务编排和底层执行彻底切开。
• Amazon S3：Transcript、Workspace 文件和 Artifact 的大后方，跨 Runtime 恢复的唯一真理源。
• Amazon DynamoDB：伺候高频结构化数据，比如消息、Skills 和 MCP。
• Amazon RDS：Space、Project、Task、Bot Binding 等核心业务主数据的铁饭碗。
• Amazon EC2：LiteLLM 网关的自留地，把模型路由和主集群隔绝开。
• Amazon CloudFront：静态资源的搬运工。
• Amazon CloudWatch：日志和监控大管家，排障全靠它。

没有一锅端，而是根据业务主数据、执行层、存储层和路由层的特性，把组件扔到了最合适的 AWS 坑位里。

9. 总结

Kollab 费劲巴拉搞这套架构，图的根本不是“怎么让大模型在软件里聊得更好”，而是“怎么让 Agent 真正把活接过去”。

从产品上看，Web、Slack、Telegram、Bot 和 CLI 全被打通到了同一个执行面；从底层上看，靠 Bedrock AgentCore 跑 Runtime，靠 Session Storage 和 S3 续命，用 EKS、DynamoDB 和 RDS 划清业务边界，最后通过 LiteLLM 和内置 CLI，完成了从“能回答”到“能干活”的蜕变。

对团队而言，最大的感知只有一点：Kollab 不再是个陪聊的花瓶，它是个能把活干完的真牛马。