上一篇我们讨论了一个变化如何把 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 ↓MergeTask最小执行单元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 ↓启动任务 ↓记录状态没有 DispatcherKanban 只是任务列表。有 DispatcherKanban 才成为自动化系统。四、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回答现在这个工作进行到哪里例如需求分析完成代码开发中。等待测试环境。二者不能互相替代。如果只有 MemoryAgent 知道历史。但不知道当前任务。如果只有 TaskAgent 知道状态。但不知道长期经验。成熟 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 更像项目管理系统模型任务创建 ↓分配角色 ↓ 执行 ↓ 等待 ↓ 恢复 ↓ 验收 ↓ 归档它适合软件开发长周期研究内容生产运维流程企业自动化。它关注管理一件事情直到完成。可以简单理解能力解决问题Tool Call我需要一个工具delegate_task我需要一个助手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. RunningAgent领取任务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.mdCoder职责代码修改测试执行技术实现输出committest reportReviewer职责代码审查风险分析质量判断输出review.mdWriter职责整理文档生成说明输出文章这时候Agent 不再是“几个不同人格的聊天机器人”。而是一个数字团队。九、Orchestrator 不应该成为超级 Agent这是 Multi-Agent 设计里非常重要的一点。很多系统最后失败是因为设计了多个 Agent。最后所有事情还是一个 Agent 做。例如Orchestrator:我先分析需求。我顺便查资料。我顺便写代码。我顺便审核。结果所有工作集中。其他 Agent 变成摆设。一个好的 Orchestrator应该像项目经理。它负责拆任务 ↓分配任务 ↓检查状态 ↓处理异常而不是亲自完成所有任务。可以类比软件团队技术负责人不会每天自己写所有代码。他的价值是让整个团队有效运行。十、完整案例从需求到 PR 的多 Agent 工作流下面看一个实际例子。需求给系统增加登录失败重试机制。Step 1Orchestrator拆解任务创建Task-001名称分析登录流程负责人Researcher输出login-analysis.mdTask-002名称设计重试方案负责人Architect依赖Task-001输出design.mdTask-003名称代码实现负责人Coder依赖Task-002输出commitTask-004名称代码审查负责人Reviewer依赖Task-003输出review.mdTask-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需要明确谁提出方案谁执行谁验证谁批准例如角色职责Orchestrator拆解任务、协调流程Researcher收集信息、验证事实Coder实现功能Reviewer质量检查Approver最终确认不要让所有 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 员工的第一步不是给它们更多自由。而是给它们一套明确的工作协议。
上一篇我们讨论了一个变化如何把 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 ↓MergeTask最小执行单元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 ↓启动任务 ↓记录状态没有 DispatcherKanban 只是任务列表。有 DispatcherKanban 才成为自动化系统。四、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回答现在这个工作进行到哪里例如需求分析完成代码开发中。等待测试环境。二者不能互相替代。如果只有 MemoryAgent 知道历史。但不知道当前任务。如果只有 TaskAgent 知道状态。但不知道长期经验。成熟 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 更像项目管理系统模型任务创建 ↓分配角色 ↓ 执行 ↓ 等待 ↓ 恢复 ↓ 验收 ↓ 归档它适合软件开发长周期研究内容生产运维流程企业自动化。它关注管理一件事情直到完成。可以简单理解能力解决问题Tool Call我需要一个工具delegate_task我需要一个助手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. RunningAgent领取任务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.mdCoder职责代码修改测试执行技术实现输出committest reportReviewer职责代码审查风险分析质量判断输出review.mdWriter职责整理文档生成说明输出文章这时候Agent 不再是“几个不同人格的聊天机器人”。而是一个数字团队。九、Orchestrator 不应该成为超级 Agent这是 Multi-Agent 设计里非常重要的一点。很多系统最后失败是因为设计了多个 Agent。最后所有事情还是一个 Agent 做。例如Orchestrator:我先分析需求。我顺便查资料。我顺便写代码。我顺便审核。结果所有工作集中。其他 Agent 变成摆设。一个好的 Orchestrator应该像项目经理。它负责拆任务 ↓分配任务 ↓检查状态 ↓处理异常而不是亲自完成所有任务。可以类比软件团队技术负责人不会每天自己写所有代码。他的价值是让整个团队有效运行。十、完整案例从需求到 PR 的多 Agent 工作流下面看一个实际例子。需求给系统增加登录失败重试机制。Step 1Orchestrator拆解任务创建Task-001名称分析登录流程负责人Researcher输出login-analysis.mdTask-002名称设计重试方案负责人Architect依赖Task-001输出design.mdTask-003名称代码实现负责人Coder依赖Task-002输出commitTask-004名称代码审查负责人Reviewer依赖Task-003输出review.mdTask-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需要明确谁提出方案谁执行谁验证谁批准例如角色职责Orchestrator拆解任务、协调流程Researcher收集信息、验证事实Coder实现功能Reviewer质量检查Approver最终确认不要让所有 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 员工的第一步不是给它们更多自由。而是给它们一套明确的工作协议。
