

> 分工的关键是责任可切：把一次前向推理，切成一条能彼此指认责任的流水线。
> Multi-Agent系列第二篇 ：Multi-Agent 三层分工的责任链

---

## 填坑

在链路上吃过单点判断器的亏之后(参考系列第一篇，使用Langchain的案例），第一反应通常是：加模型、加轮数、换更强的底座。结果呢？更贵、更慢，错还是错，只是错得更体面。后来发现，真正把局面掰回来的，是一次彻底的重构：把一个人能拍板的事，拆成一组彼此能负责的人。

具体的, 早期判断一个方案到底该不该上线，依赖的是"一个 Agent 看完所有材料拍板或者提出建议等待HITL"。它大部分时候对，但这个"大部分时候"掩盖了一件致命的事：没人知道它哪一环会出错。于是我们把它拆成了三层：第一层负责"这个需求该怎么拆、该找谁论证"（调度），第二层负责"给出论证、给出可测的约束、接受对抗审查"（执行），第三层负责"把这次结论、它的依据、它被证伪还是被采纳，全部留痕归档"（知识）。

这么做的目标，并不是希望能把判断本身变聪明，反而是在追求知其然知其所以然，让它变得可以被管理。

## 拆解黑盒

很多人以为多 Agent 的"多"就是数量问题。这是个属于人的“幻觉”。单点判断器能被切开，是因为它里面的四个环节（理解、拆解、执行、自检）本来就是四种不同的动作，只是被熔在了一次前向推理里。 逐层问每一个模型，谁都不能向你交代；但把这四个动作分给四类明确的职责，每一类就能单独被检验。

![图片](https://developer.qcloudimg.com/http-save/yehe-11918656/f010b246246aaf64e575c2bb6da1dc99.png)

图 ｜分工是把判断切得可问责

</div>

那么切成几层才够？实践下来，我觉得三层就差不多了：调度层可指认（这次活儿是谁派错的）、执行层可证伪（这个方案能不能被反驳）、知识层可复核（这个结论的依据全不全）。上图把这条链画出来了：从"一次前向推理"的黑盒，到调度 / 执行 / 知识三层。

核心思想是对Multi-Agent分工的定义边界的思考：不同环节由不同的、可被分别指认的对象执行，且环节之间有明确的交接与责任归属。

也可以看看明星项目的做法。包括Multi-Agent在内的如何利用大模型的Agent相关技术还在发展早期，对于明星项目的使用，要边学习边思考。 

## 责任可切才是分工

构建Multi-Agent最初的尝试的时候，绕不开对现有框架，比如CrewAI的学习：CrewAI 教给我们一件好东西，角色（role）。把一个 Agent 定义成"研究专员""审查员""决策者"，让不同的 prompt 和工具去承担不同的活。这是在切分工的范本，值得学习。

但当用CrewAI反复在自己的软件开发中进行实践，却发现，角色只解决了"分工的一半"。角色定义了"该叫什么名字"，却没定义"出错了怎么算账"。 CrewAI 的组合通常解决"谁做什么"，很少解决"谁对它做的负责、用什么证据负责、出了岔子在哪个环节被抓住"。于是很多用 CrewAI 搭出来的多 Agent，看起来角色分明，实际上还是一个"各司其职、无人问责"的松散外包，而且比较头疼的是，如果想搭建一个“弹性”工作流，在各个角色之间形成战斗力，就非常的不稳定。

CrewAI 的角色字段值得再拆一层看，因为缺的东西恰恰藏在字段里。一个 Agent 的定义通常包含 role（叫它什么）、goal（它想达成什么）、backstory（它的人设背景）三个字段，再加挂工具和一个 llm。这些字段把"身份"写得非常清楚，但对"交接"只字未提。两个角色之间传出去的结论，由哪个字段记录它传给了谁、原样传了没有、对方有没有照单收敛？再看 CrewAI 的编排图，我们看到的是 dependencies 和 process 决定流程怎么走，却没有一张内置的账本去问"这一棒到底落在谁手里、掉没掉"。所以项目实践中，才会有那种别扭的感觉，用 CrewAI 搭出来的角色越细分，出错时越像"拼图少了一块"，却永远说不清是哪块。

::: center  
![图片](https://developer.qcloudimg.com/http-save/yehe-11918656/efd081930691192b558bc066b13038a9.png)
:::
Multi-Agent 的理想状态应该是不同的：我们把责任的可切性当作第一性约束来设计，角色只是可切性落地后的副产品。 三层就是三个问责点：调度对"派对活"负责，执行对"论证可证伪"负责，知识对"留痕可复核"负责。

分工首先要切开的是责任，角色只是副产品。

## 一次自省和返工

分工完成了，也不是就可以当甩手掌柜了，还要更进一步的管理，保证Agent们正常出活儿，分享个有趣有比较糟心的使用Multi-Agent的经历。

目标是完成一个比较复杂的业务系统的单据流转的模块，需求和边界都比较清晰，难度就是单据处理的情况比较多，分析下来是比价适合多Agent来逐个层次拆解和执行的。配置了双层Agent构架（主从Agent分工明确），使用了Multi-Agent的分工逻辑（调度、执行、知识），但没注意的是，三层的职责边界是糊的：调度层偶尔自己上手执行，执行层偶尔自己补留痕，知识层偶尔还想当裁判。结果是最常见的那种失败：三个角色互相推诿，谁都不为最终结论负责，因为责任缝被糊掉了。 出错时，调度怪执行"你没照约束做"，执行怪调度"你派的活就不对"，知识层在旁边说"我记录的都是你们喂的"。

我这里没有用任何的夸张的来形容这几个Agent当时对被抓包的反应类人化，我那一刻是感觉既无力、生气，又有种，“这几位大哥在我手里是成精了”的喜感，五味杂陈。

想了想，Multi-Agent的方向应该是没问题的，可能还是我这个管理者没有管好，权责利没统一。返工的关键，是把可指认、可证伪、可复核，分权分开，而且责任界定清晰（为此我还在规约中做了三份文件，WBS、 TestCase、 Issue Log，用来给Multi-Agent的管理做辅助）。

给参与项目的Multi-Agent的责任分好层，并为每一层的责任又加了一份规约（契约）：调度不产出方案，只产出"派给谁 + 为什么派给它"；执行不直接写进账本（WBS或者完工证明），只产出"可被反驳的论证 + 可复现的基准"（管理Test Case和Issue Log）；知识层不评判对错，只负责"事实入库、可信度校准、坑位复盘"。

| 层   | 只交付                 | 用哪份证据自证                | 错了从哪条缝抓  |
|:---:| ------------------- | ---------------------- | -------- |
| 调度  | 派给谁 + 为什么派给它        | 派单记录（含时间戳、目标、负责 Agent） | 这一棒派错在哪  |
| 执行  | 可被反驳的论证 + 可复现的基准    | 复现脚本 / 输入输出样本 / 对抗审查记录 | 论证缺口在哪一步 |
| 知识  | 事实入库 + 可信度校准 + 坑位复盘 | 留痕行（含依据、被证伪否、回流入账时间）   | 依据漏了哪一条  |

返工后的"团队"不再开会吵"谁该负责"，而是直接翻某一列：这轮留痕行少了时间戳，第一时间指向知识层，而不是整条链背锅。"追不到人"是分工最常见的假死。团队里有过一份纸上责权表，写得很全，每种角色都有一行，可实际跑起来时，调度把活派给"执行团队"而不是一个具名的 Agent，执行把结论写进一个没人复核的便签，知识层的留痕根本没有落盘。

在“调教”Multi-Agent的过程中，时常会有“在打交道的不是Agent，而是真的人“的感觉，作为管理者，你似乎在很短的时间里，和这些Agent相处中，完整经历了一次管理经验甚至人生经验的复盘。

## HITL也不是拍脑袋

> 采用Multi-Agent去尝试完成的任务或项目，多半不是个简单的活。一个不是那么简单的活，肯定是由很多个很复杂的任务和判断构成，一个复杂的判断，等价于一组彼此可指认、可证伪、可复核的环节之和，分工的价值在于"拆开了才能被管理"，因为你终于可以对"哪一个环节"问责。这大概就是构建Multi-Agent的精髓。

为什么单 Agent 有天花板，因为不可切。 一个不可切的整体，无论多强，出错了都没有可下手的地方。Multi-Agent是把一个判断切成可审计的工序。 是分工和责任的明晰，把服务人为决策（HITL）从不可管理变成了可管理。

分工是分了，但怎么保证每一环都真的负责？ 下一篇吧。

---
王海涛（公众号：Jia言Yi行 · GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）

分工的关键是责任可切：把一次前向推理，切成一条能彼此指认责任的流水线。 Multi-Agent系列第二篇 ：Multi-Agent 三层分工的责任链

Multi-Agent: 这几位“大哥”在我手里成了精

采用Multi-Agent去尝试完成的任务或项目，多半不是个简单的活。一个不是那么简单的活，肯定是由很多个很复杂的任务和判断构成，一个复杂的判断，等价于一组彼此可指认、可证伪、可复核的环节之和，分工的价值在于"拆开了才能被管理"，因为你终于可以对"哪一个环节"问责。这大概就是构建Multi-Agent的精髓

 CTO

人工智能

后端

职业发展

分工的核心是责任可切：将一次前向推理拆解为调度、执行、知识三层，每层独立问责。调度负责派活并留痕，执行产出可证伪论证，知识层确保留痕可复核。通过清晰契约与WBS/TestCase/IssueLog辅助，实现从黑盒判断到可审计工序的转变，解决单Agent不可切痛点，提升Multi-Agent管理的稳定性与可追溯性。

软件开发

GitHub

CrewAI 

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Multi-Agent: 这几位“大哥”在我手里成了精-腾讯云开发者社区-腾讯云

Multi-Agent: 这几位“大哥”在我手里成了精

Multi-Agent: 这几位“大哥”在我手里成了精

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐