从 AI Worker 到 AI Team：为什么多 Agent 协作需要 Kanban

上一篇我们讨论了一个变化：如何把 Hermes 从一个聊天机器人改造成一个 24 小时运行的 AI 工作台。

但当一个 Agent 变成多个 Agent，新的问题马上出现：

一个 AI 会工作，不代表一群 AI 会协作。

多 Agent 真正困难的地方，不是让更多模型参与，而是让它们像一个团队一样完成任务。

开篇：为什么多 Agent 最后都会变成群聊？

过去一年，大模型应用有一个明显趋势：

从：

用户提问-->AI回答

逐渐走向：

用户提出目标-->Agent规划任务-->调用工具执行-->产生结果

这就是从 Chatbot 到 AI Worker 的变化。

但是，当我们进一步增加 Agent 数量时，很多系统会遇到一个奇怪的问题：

一开始看起来很先进：

Planner Agent：我负责拆解任务。Research Agent：我负责查资料。Coder Agent：我负责写代码。Reviewer Agent：我负责检查质量。

几个 Agent 相互沟通，好像一个完整团队。

但真正运行一段时间以后，问题开始暴露：

• Planner 不知道 Coder 做到了哪里；

• Coder 不知道 Research 的结论是否已经确认；

• Reviewer 不知道当前代码是不是最新版本；

• 任务失败以后，没有人知道应该从哪里恢复；

• 人类加入以后，也不知道应该在哪个节点介入。

最后系统变成：

Agent A：我已经完成第一步。Agent B：好的，我继续。Agent C：等等，我发现之前的数据可能不对。Agent A：我记得不是这样。Agent B：上下文已经压缩了，我重新看看。

看起来像团队。

实际上只是一个没有项目管理能力的群聊。

真正的问题不是模型能力。

而是：

聊天记录不是任务状态。

人类团队为什么需要项目管理工具？

不是因为人不会沟通。

而是因为复杂任务必须有：

• 明确负责人；

• 当前状态；

• 交付物；

• 依赖关系；

• 历史记录；

• 恢复路径。

软件团队有 Jira、Linear、Trello。

研发流程有 Git、CI/CD。

企业业务有 BPM、流程引擎。

这些系统解决的本质都是同一个问题：

让工作状态脱离个人记忆，成为系统可管理的对象。

而多 Agent 协作，同样需要这个能力。

这也是 Hermes Kanban 出现的原因。

它解决的不是：

“如何让更多 Agent 聊天。”

而是：

如何让多个 Agent 围绕任务进行协作。

一、Agent 数量增加，不等于团队形成

很多人第一次设计 Multi-Agent 系统时，会自然采用这样的思路：

增加角色。

比如：

一个 Agent 负责规划一个 Agent 负责搜索一个 Agent 负责写作一个 Agent 负责审核

看起来很合理。

但是角色增加，只解决了：

谁可以做什么。

没有解决：

什么时候做？

做到哪里？

下一步是谁？

如果失败怎么办？

1. 单 Agent 时代，问题隐藏在上下文里

单 Agent 工作时：

用户--Agent--工具--结果

上下文承担了很多责任。

Agent 记得：

• 用户目标；

• 当前进度；

• 已经尝试的方法；

• 下一步计划。

但是多 Agent 后：

上下文被拆开了。

变成：

Planner | ------------------------- | | |Research Coder Reviewer

每个 Agent 都拥有自己的上下文。

于是出现第一个问题：

状态丢失

例如：

Research Agent 完成资料收集。

它告诉 Planner：

“我整理好了。”

但是：

哪里保存？

有哪些来源？

哪些结论已经验证？

哪些只是猜测？

如果没有外部状态，Planner 接下来只能相信一句话。

而一句话不是工作记录。

2. 多 Agent 最大的问题：没有共同工作空间

人类团队协作时：

项目经理不会告诉开发：

“我脑子里记得需求，你开始写吧。”

而是会提供：

• 文档；

• 需求单；

• 设计稿；

• 代码仓库；

• Issue。

因为团队成员需要共享事实。

Agent 也是一样。

一个可靠的 Agent Team，需要：

共享任务状态共享任务目标共享交付标准共享历史记录

而不是：

A告诉B一句话B根据这句话继续猜

3. 没有任务边界，Agent 会互相越权

另一个常见问题：

角色定义了，但职责没有隔离。

例如：

Planner：

我先帮你优化一下代码。

Coder：

我觉得需求应该重新定义。

Reviewer：

这个问题我直接修改。

每个 Agent 都很积极。

但是结果是：

没有责任边界。

最后出现：

• 谁决定了方案？

• 谁修改了代码？

• 谁验证了结果？

• 谁批准上线？

没人知道。

优秀的人类团队不是因为每个人都主动。

而是因为：

每个人知道自己什么时候主动，什么时候等待。

Agent 团队同样如此。

二、多 Agent 缺少的不是智能，而是任务状态

如果观察目前大部分 Agent 框架，会发现一个共同趋势：

大家越来越关注：

• 更大的模型；

• 更多工具；

• 更强推理；

• 更多插件。

但是复杂任务真正的瓶颈，往往不是这些。

而是：

缺少一个任务状态层。

一个成熟的软件系统通常分三层：

业务层流程层数据状态层

例如订单系统：

创建订单 ——> 支付中 ——> 已支付 ——> 配送中 ——> 完成

系统不是靠聊天知道订单状态。

而是靠状态机。

Agent 工作流也一样。

一个代码开发任务：

不能只是：

帮我增加登录重试功能

然后等待几个 Agent 聊完。

它应该成为：

Task:实现登录失败重试Owner:Coder AgentStatus:RunningDependency:登录流程分析完成Output:代码修改 + 测试报告Review:Reviewer Agent

当任务成为一个独立对象以后：

很多能力才会出现：

• 可以暂停；

• 可以恢复；

• 可以重新分配；

• 可以查看历史；

• 可以人工介入。

聊天记录 ≠ 工作状态

这是理解 Multi-Agent 的关键。

很多人会误认为：

“有完整聊天记录，所以 Agent 知道发生了什么。”

实际上不是。

聊天记录回答：

过去说了什么。

任务状态回答：

当前应该做什么。

两者完全不同。

例如：

聊天：

Coder：我修改了认证模块。

任务状态：

Task:修改认证模块Status:review_pendingChanged files:auth/login.pyTest:pytest auth/test_login.pyReviewer:waiting

后者才是团队协作需要的信息。

所以，多 Agent 系统真正需要的，不是：

更多聊天窗口。

而是：

一个让所有 Agent 围绕任务工作的共享状态空间。

这就是 Kanban 的核心价值。

三、Kanban：把聊天协作变成任务状态机

如果说上一篇文章中，我们讨论的是：

如何让一个 Agent 从“等待提问”变成“持续执行任务”。

那么这一篇讨论的是：

如何让多个 Agent 从“互相聊天”变成“围绕任务协作”。

中间缺少的关键层，就是：

任务状态管理。

很多人第一次看到 Kanban，会自然想到：

• 一个任务卡片页面；

• 可以拖动的列表；

• 类似 Jira、Trello 的项目管理工具。

这些都只是表象。

对于 Agent 系统来说，Kanban 最重要的价值不是展示任务。

而是：

把任务变成一个独立存在、可以被系统管理的对象。

1. 从“消息流”转向“任务流”

传统聊天式 Agent：

用户消息 ↓Agent A ↓Agent B ↓Agent C ↓最终回答

所有状态都存在消息里。

问题是：

消息是线性的。

任务却不是。

真实工作往往是：

需求分析 | +------ 数据调研 | +------ 技术设计 | +------ 开发实现 | ↓ 测试验证 | ↓ 发布准备

这是一个有依赖关系的流程。

不是一段聊天。

Kanban 做的事情，就是把：

“我要完成一个目标”

拆成：

任务 Task +负责人 Assignee +状态 Status +依赖 Dependency +工作空间 Workspace +执行记录 History

这样任务才具备生命周期。

例如：

用户提出：

为系统增加登录失败重试机制。

聊天方式：

Planner：我分析一下。Coder：我写代码。Reviewer：我看看。完成。

看似完成。

但没有任何工程信息。

Kanban 方式：

任务1：

名称：分析当前登录流程负责人：researcher状态：done输出：login-flow-analysis.md

任务2：

名称：实现登录失败重试负责人：coder状态：running依赖：task-001工作区：worktree/login-retry

任务3：

名称：代码审查负责人：reviewer状态：blocked等待：task-002完成

这时候：

任何 Agent 或人类加入，都能知道：

• 当前发生什么；

• 谁负责；

• 下一步是什么。

这就是从：

对话协作

升级为：

工作流协作。

2. Hermes Kanban 的核心对象

从工程角度看，一个可运行的 Agent 协作系统，需要几个核心对象。

Board：任务空间

Board 可以理解为：

一类工作的集合。

例如：

AI研发任务板技术研究任务板内容生产任务板运维巡检任务板

不同类型任务可以拥有不同流程。

例如：

内容生产：

发现选题 ↓资料收集 ↓文章生成 ↓事实审核 ↓ 发布

代码开发：

需求分析 ↓ 开发 ↓ 测试 ↓Review ↓Merge

Task：最小执行单元

Task 是 Kanban 的核心。

一个 Task 不应该只是：

帮我处理一下。

而应该包含：

目标：明确要完成什么。负责人：哪个 Agent 执行。输入：读取什么资料。输出：产生什么结果。验收：什么条件算完成。

例如：

一个研究任务：

task: title: "分析最新 Agent 框架趋势" assignee: researcher input: - arxiv - github - 官方博客 output: - research-report.md acceptance: - 至少10个案例 - 每个案例有来源 - 标注商业价值

注意：

这里已经非常接近企业任务管理系统。

因为 Agent 不再接受一句自然语言。

而是接受一个结构化工作单。

Link：任务依赖关系

复杂任务一定不是线性的。

例如：

写一篇技术文章：

需要：

资料收集 | ↓技术分析 | ↓文章撰写 | ↓事实审核

那么：

写作任务不能提前开始。

因为它依赖资料。

这就是 Link 的价值。

它描述：

哪些任务必须先完成。

Comment：交接记录

很多 Agent 系统忽略这一点。

但是团队协作中：

交接比执行更重要。

例如：

Research Agent 完成任务：

错误：

完成了。

正确：

完成技术调研。已确认：1. Hermes支持Kanban任务调度2. Dispatcher运行于Gateway3. Task状态持久化保存产物：/research/hermes-kanban.md待注意：官方版本差异需要再次核验。

这才是下一位 Agent 能理解的信息。

Workspace：执行现场

任务不能只存在数据库。

还需要真实工作环境。

例如：

代码任务：

Workspace:/project/worktree/login-retry

研究任务：

Workspace:/research/hermes-analysis

写作任务：

Workspace:/articles/hermes-series

因为 Agent 最终需要：

• 读文件；

• 写文件；

• 调工具；

• 保存结果。

Dispatcher：任务调度器

这是多 Agent 系统非常关键的一层。

它负责：

发现任务 ↓判断是否ready ↓选择执行Agent ↓启动任务 ↓记录状态

没有 Dispatcher：

Kanban 只是任务列表。

有 Dispatcher：

Kanban 才成为自动化系统。

四、Kanban 不是看板，而是 Agent 协作协议

这里有一个重要区别。

很多人认为：

我已经有聊天记录了，再加一个 Kanban 页面就行。

实际上不是。

Kanban 的意义不是增加一个 UI。

而是建立一套协作协议。

人类团队协作：

需求 ↓任务单 ↓负责人 ↓ 执行 ↓ 验收 ↓ 归档

Agent 团队也需要：

Task Created ↓Assigned ↓Running ↓Blocked / Done ↓Verified ↓Archived

换句话说：

Kanban 给 Agent 增加了一层：

外部状态记忆

上一篇我们讨论 Memory。

很多人容易混淆：

Memory 和 Task State。

它们解决的问题不同。

Memory：

回答：

这个 Agent 过去知道什么？

例如：

用户喜欢中文输出。项目使用Python。团队采用某种代码规范。

Task State：

回答：

现在这个工作进行到哪里？

例如：

需求分析完成代码开发中。等待测试环境。

二者不能互相替代。

如果只有 Memory：

Agent 知道历史。

但不知道当前任务。

如果只有 Task：

Agent 知道状态。

但不知道长期经验。

成熟 Agent 系统需要：

Memory + Task State + Workspace

共同组成工作基础。

五、delegate_task 和 Kanban：临时助手 vs 长期团队

Hermes 中还有一个容易混淆的能力：

delegate_task

很多人会问：

既然可以让 Agent 调 Agent，为什么还需要 Kanban？

答案：

因为它们解决的问题完全不同。

1. delegate_task 更像函数调用

模型：

Parent Agent |Child Agent | 返回结果

它适合：

• 查一个资料；

• 分析一个问题；

• 生成一个短结果。

例如：

请帮我分析一下这个报错原因。

子 Agent 返回：

原因可能是配置错误。

任务结束。

它关注：

获取一个结果。

2. Kanban 更像项目管理系统

模型：

任务创建 ↓分配角色 ↓ 执行 ↓ 等待 ↓ 恢复 ↓ 验收 ↓ 归档

它适合：

• 软件开发；

• 长周期研究；

• 内容生产；

• 运维流程；

• 企业自动化。

它关注：

管理一件事情直到完成。

可以简单理解：

一个简单判断标准

如果你的任务：

5分钟内完成。

比如：

帮我总结这个网页。

不用 Kanban。

如果你的任务：

可能持续几小时、几天。

例如：

完成一个产品调研报告。

需要：

• 搜资料；

• 分析；

• 写作；

• 审核；

• 修改。

这时候 Kanban 才有价值。

六、为什么多 Agent 必须从“聊天”进入“任务协议”

到这里，可以总结一下：

聊天模式：

Agent之间交换消息

问题：

• 状态丢失；

• 无法恢复；

• 责任模糊；

• 难以审计。

Kanban模式：

Agent围绕任务协作

优势：

• 有任务；

• 有负责人；

• 有状态；

• 有依赖；

• 有工作区；

• 有历史记录。

所以：

多 Agent 的核心问题，不是让 Agent 之间交流更多，而是让它们共享一个可靠的工作状态。

这也是 Hermes Kanban 真正解决的问题。

七、Hermes Kanban 如何管理一个任务生命周期

理解 Kanban 最好的方式，不是看它如何创建任务，而是看一个任务从产生到完成，中间经历了什么。

一个成熟的 Agent 工作流，不应该是：

收到需求 ↓Agent 开始执行 ↓输出结果

而应该是：

任务产生 ↓任务分析 ↓任务准备 ↓Agent执行 ↓结果验证 ↓完成归档

也就是：

任何任务都应该拥有生命周期。

1. 一个任务，不应该直接进入执行

很多 Agent 系统的问题，是任务一创建，就马上让模型开始工作。

例如：

用户：

帮我分析一下今年 AI Agent 的趋势。

Agent：

马上搜索。

马上总结。

马上输出。

但是：

它有没有明确目标？

有没有定义范围？

有没有确定输出格式？

有没有判断是否需要拆分？

这些问题如果不解决，后面一定返工。

因此，一个更合理的流程：

用户需求 ↓ Triage分析 ↓ Task拆解 ↓ Ready队列 ↓ Agent执行

2. Triage：先判断任务是什么

triage是很多团队容易忽略的一步。

它不是执行。

而是判断：

这个事情应该怎么做。

例如：

用户提出：

帮我写一份智慧园区 AI 方案。

Triage Agent 不应该马上写方案。

它应该拆：

任务1：分析行业背景任务2：整理客户需求任务3：设计总体架构任务4：输出技术方案任务5：审核商业价值

然后创建任务链。

Triage解决的是：

不要让 Agent 直接面对模糊目标。

3. Ready：任务什么时候可以执行

一个常见误区：

创建任务 = 可以执行。

实际上不是。

任务可能存在：

• 缺输入；

• 缺依赖；

• 缺权限；

• 缺环境。

例如：

Coder Agent 接到：

实现支付功能。

但是：

Research Agent 还没有完成：

• 支付流程分析；

• 接口定义；

• 数据模型确认。

如果强行执行：

Coder只能猜。

所以需要：

todo ——> ready

这个状态转换。

只有满足：

输入完整 + 依赖完成 + 执行环境存在

任务才进入 ready。

4. Running：Agent领取任务

Dispatcher 发现：

Task:实现登录重试Status:readyAssignee:coder

然后：

启动对应 Profile。

流程：

Dispatcher ↓Coder Profile ↓Workspace ↓开始执行

这里有一个重要设计：

Agent 不应该自己寻找工作。

而应该：

由任务系统分配工作。

为什么？

因为如果 Agent 自己抢任务，会出现：

• 重复执行；

• 权限混乱；

• 优先级失控。

5. Blocked：失败不是结束，而是状态

这是 Agent 工作流和普通脚本最大的区别。

传统自动化：

失败：

ERROR ——> 停止

Agent 工作流：

失败：

Blocked ——> 等待恢复

例如：

Coder：

发现：

数据库字段定义不存在

正确行为：

不是：

根据经验猜一个字段。

而是：

状态：blocked原因：缺少数据库设计文档等待：Architect Agent确认

这非常关键。

因为：

一个可靠的 Agent，不应该在不知道的时候继续行动。

6. Done：完成必须有验收信息

很多自动化系统最大的问题：

完成状态没有意义。

例如：

Status:done

然后结束。

但是：

完成什么？

怎么验证？

在哪里？

有什么风险？

都不知道。

一个工程级完成状态应该包含：

Summary:完成登录重试机制。Changed:auth/login.pyValidation:pytest test_auth.pyRisk:旧客户端错误码保持兼容。

所以：

Done 不是：

“Agent说做完了”。

Done 是：

“任务满足验收条件”。

八、Profile + Kanban：构建真正的 Agent Team

如果说 Kanban 解决：

任务如何流转。

那么 Profile 解决：

谁来执行任务。

两者结合，才形成 Agent Team。

上一篇文章讲过：

Profile 不是简单角色扮演。

它解决的是：

• 配置隔离；

• 工作方式隔离；

• Skill隔离；

• Memory隔离。

在 Multi-Agent 中：

Profile 就相当于：

不同岗位。

例如：

Orchestrator

职责：

需求理解任务拆解依赖管理角色分配

禁止：

直接修改代码直接发布结果

Researcher

职责：

资料收集事实验证行业分析

输出：

research.md

Coder

职责：

代码修改测试执行技术实现

输出：

committest report

Reviewer

职责：

代码审查风险分析质量判断

输出：

review.md

Writer

职责：

整理文档生成说明输出文章

这时候：

Agent 不再是：

“几个不同人格的聊天机器人”。

而是：

一个数字团队。

九、Orchestrator 不应该成为超级 Agent

这是 Multi-Agent 设计里非常重要的一点。

很多系统最后失败，是因为：

设计了多个 Agent。

最后：

所有事情还是一个 Agent 做。

例如：

Orchestrator:我先分析需求。我顺便查资料。我顺便写代码。我顺便审核。

结果：

所有工作集中。

其他 Agent 变成摆设。

一个好的 Orchestrator：

应该像项目经理。

它负责：

拆任务 ↓分配任务 ↓检查状态 ↓处理异常

而不是：

亲自完成所有任务。

可以类比软件团队：

技术负责人不会：

每天自己写所有代码。

他的价值：

是让整个团队有效运行。

十、完整案例：从需求到 PR 的多 Agent 工作流

下面看一个实际例子。

需求：

给系统增加登录失败重试机制。

Step 1：Orchestrator拆解任务

创建：

Task-001

名称：

分析登录流程

负责人：

Researcher

输出：

login-analysis.md

Task-002

名称：

设计重试方案

负责人：

Architect

依赖：

Task-001

输出：

design.md

Task-003

名称：

代码实现

负责人：

Coder

依赖：

Task-002

输出：

commit

Task-004

名称：

代码审查

负责人：

Reviewer

依赖：

Task-003

输出：

review.md

Task-005

名称：

生成PR说明

负责人：

Writer

依赖：

Task-004

输出：

pull-request.md

整个流程：

用户需求 ↓ Orchestrator ↓ ----------------------- ↓ ↓ ↓ Research Design Coding ↓ ↓ ↓ Review ↓ PR说明

如果中间失败怎么办？

假设：

Coder执行失败。

传统 Agent：

重新开始。

Kanban：

状态：

Task-003Status:blockedReason:测试环境不可用

环境恢复：

blocked ↓ready ↓running

继续执行。

之前结果保留。

这就是任务系统最大的价值：

失败成为一种状态，而不是一次灾难。

十一、为什么 Kanban 是 Multi-Agent 的基础设施

到这里，可以看到：

Multi-Agent 真正缺少的不是：

更多模型。

不是：

更多 Prompt。

甚至不是：

更多工具。

而是：

一个所有 Agent 都认可的工作协议。

这个协议至少包含：

任务是什么谁负责当前状态依赖关系工作空间结果在哪里如何验证失败怎么办

而 Kanban 正好提供了这些基础能力。

所以：

如果上一篇解决的是：

一个 Agent 如何成为 Worker。

那么 Kanban 解决的是：

多个 Worker 如何组成 Team。

十二、多 Agent 系统最容易踩的坑

当我们开始构建 Multi-Agent 系统时，很容易陷入一个误区：

看到 Demo 运行成功，就认为系统已经具备生产能力。

实际上，Demo 和长期运行的 Agent Team，中间还差很多工程问题。

一个真正可用的多 Agent 系统，不只是：

多个模型 + 多个角色 + 多个 Prompt

而是：

任务管理 + 状态管理 + 权限管理 + 质量控制 + 运行治理

下面是实际落地过程中最容易遇到的问题。

1. 坑一：把 Agent 当成聊天成员，而不是执行角色

这是最常见的问题。

很多设计一开始是：

Planner：你帮我分析一下。Coder：好的，我开始。Reviewer：我看看。

看起来像团队。

但实际上，每个 Agent 都只是聊天参与者。

问题在于：

聊天没有责任边界。

一个成熟的 Agent Team，需要明确：

谁提出方案？谁执行？谁验证？谁批准？

例如：

不要让所有 Agent 都拥有：

• 修改文件权限；

• 发布权限；

• 删除权限；

• 外部通信权限。

否则：

Agent 越聪明，风险越大。

2. 坑二：任务描述像愿望，不像工程需求

很多人给 Agent 的任务：

帮我优化一下系统。研究一下这个方向。写一个方案。

对于人类来说还能理解。

对于 Agent 来说：

缺少执行边界。

一个好的任务应该包含：

目标输入限制输出验收标准

例如：

错误：

优化登录体验。

正确：

目标：增加登录失败自动重试。输入：现有认证模块代码。限制：不修改数据库结构。输出：代码提交 + 测试报告。验收：连续失败3次后进入安全限制。

Agent 最大的问题不是不会做。

而是不知道：

什么叫做完成。

3. 坑三：让 Orchestrator 变成万能 Agent

这是非常典型的架构退化。

设计：

一个调度Agent + 多个执行Agent

最后：

调度Agent：我自己分析。我自己搜索。我自己写。我自己检查。

然后：

其他 Agent：

“等待调用。”

这实际上退回到了：

单 Agent 模式。

一个好的 Orchestrator：

应该负责：

理解目标 ↓拆分任务 ↓创建依赖 ↓分配角色 ↓跟踪状态

它最大的价值：

不是完成工作。

而是：

让工作可靠发生。

4. 坑四：没有人为介入节点

很多人设计 Agent 系统时，希望：

100% 自动化。

但现实中：

完全无人值守通常不是最佳方案。

尤其涉及：

• 生产部署；

• 商业决策；

• 对外发布；

• 数据删除；

• 权限修改。

应该设计：

Human-in-the-loop。

例如：

Agent完成代码修改 ↓自动测试 ↓Reviewer Agent检查 ↓人工批准 ↓合并发布

人工不是替代 Agent。

而是负责：

高风险决策。

5. 坑五：只保存结果，不保存过程

很多系统：

最后给你一个答案。

但是：

你不知道：

• 为什么这么判断；

• 查过什么资料；

• 调用了什么工具；

• 哪个 Agent 做出的决定。

对于生产系统：

这是不可接受的。

企业需要：

Agent Observability（可观测性）。

至少记录：

任务ID执行Agent开始时间结束时间调用工具输入输出状态变化异常信息

未来企业管理 Agent，很可能像管理服务器一样：

需要：

• 日志；

• 指标；

• 链路追踪。

十三、企业为什么需要 Agent 协作协议

如果把单 Agent 看成：

一个数字员工。

那么 Multi-Agent 就是一支数字团队。

而团队最大的挑战：

永远不是个人能力。

而是协作机制。

人类企业经过几十年发展，形成：

• 项目管理；

• 流程管理；

• 权限体系；

• 审批机制；

• 质量体系。

这些不是因为人不聪明。

而是因为：

复杂工作必须依赖系统。

Agent 团队同样如此。

未来企业不会只有：

一个超级 Agent。

更可能是：

AI Manager | -------------------------------- | | |Research Coding Operation | | |知识库 代码库 业务系统 | Governance

而 Kanban 这样的任务系统，就是其中的：

协作基础设施。

十四、国内团队如何开始落地 Multi-Agent

很多企业看到 Agent Team，会直接想到：

“是不是可以让 AI 自动完成整个研发流程？”

我的建议：

不要一开始追求全自动。

应该从：

低风险、高重复、有明确产物的任务开始。

场景一：AI 研究团队

这是最容易落地的。

例如：

每天生成行业情报：

Researcher ↓收集资料Analyst ↓判断价值Writer ↓生成报告Reviewer ↓检查事实

优势：

• 风险低；

• 结果可人工审核；

• 容易衡量效果。

场景二：技术研发辅助

不要直接让 Agent 自动提交生产代码。

先做：

需求分析 ↓技术方案 ↓代码生成 ↓测试 ↓Review ↓生成PR说明

人负责：

最终合并。

场景三：运维巡检

例如：

每天：

检查系统状态 ↓分析异常日志 ↓定位可能原因 ↓生成处理建议

如果需要：

再进入人工处理流程。

这些场景共同特点：

都有：

• 明确输入；

• 明确输出；

• 明确验收。

这正是 Kanban 最适合的地方。

十五、从 AI Worker 到 AI Team，真正变化是什么？

回顾整个过程。

第一阶段：

Chatbot：

用户问 ↓AI答

第二阶段：

AI Worker：

任务进入 ↓Agent执行 ↓结果交付

第三阶段：

AI Team：

目标输入 ↓任务拆解 ↓多个Agent协作 ↓状态管理 ↓结果验收 ↓持续优化

真正的变化不是：

用了更多 Agent。

而是：

工作方式发生变化。

以前：

人管理任务。

AI提供帮助。

未来：

人管理目标和规则。

AI管理执行过程。

但前提是：

AI必须拥有：

• 清晰任务；

• 明确角色；

• 可追踪状态；

• 可恢复流程。

结尾：未来 AI 团队管理的是任务，而不是聊天

多 Agent 的未来，不是建立一个越来越热闹的 AI 群聊。

因为聊天解决的是：

表达。

而复杂工作需要：

协作。

一个真正可工作的 AI Team，应该具备：

有身份有任务有状态有工作空间有依赖关系有交接记录有恢复能力有审计过程

Hermes Kanban 的意义，也不只是增加了一块任务板。

它代表了一种变化：

从：

Agent之间交换消息

走向：

Agent围绕任务协作

如果上一篇文章解决的是：

如何把 Hermes 变成一个 24 小时 AI Worker。

那么这一篇解决的是：

如何让多个 AI Worker 组成一个可靠的 AI Team。

未来企业真正需要管理的，不会只是模型。

而是：

一群可以持续工作的 AI 员工。

而管理 AI 员工的第一步：

不是给它们更多自由。

而是给它们一套明确的工作协议。