多Agent（智能体）如何合理分工

摘要：一、多Agent分工的痛点 二、合理分工的原则与方法 三、必须避开的反面模式

一、多Agent分工的痛点 搭建多Agent系统本身不难，但分工不合理会导致严重问题，比如多个Agent并行编辑同一文件时，极大可能把代码搞得一团糟，引发合并冲突等灾难。 二、合理分工的原则与方法 按隔离边界分工（核心原则） 要严格按照隔离边界切分任务，绝对不能按功能列表分工。 正面例子：让Agent A负责后端API，Agent B负责前端页面，各自在独立目录工作，“井水不犯河水”。 反面例子：让Agent A写用户注册、Agent B写用户登录，若两者编辑同一文件，会因疯狂修改导致系统崩溃。牢记：两个Agent永远不应编辑同一个文件。 选择合适的分发机制（多Agent决策树） 派发任务前，需快速问自己三个问题： 任务依赖当前对话上下文吗？ 执行时长会超过五分钟吗？ 并行的Agent之间需要互相协调进度吗？ 对应分发机制： 依赖上下文的短任务：用/queue排队。 独立且超5分钟的任务：用/background扔到后台。 独立且短于5分钟的任务：用delegate_task。 需重度协调的大型项目：用tmux。 delegate_task的硬限制 系统默认并行数有限，需防算力滥用。 不允许“套娃”，即子Agent不能再派发自己的子任务，代理层级需保持扁平。 父Agent派发任务后会被同步阻塞，需等待结果，且子Agent在此过程中无法与人类用户互动。 若有大量并行小任务，需拆分批次，每批不超过系统并行上限。 tmux：跨语言重型武器 适用于大型工程的多实例编排。开启walk tree模式后，每个Agent会有完全独立的git分支工作区，从根源上避免代码冲突。还可按需为不同Agent分配不同模型（简单任务用便宜模型，重体力活用大模型）。 上下文防火墙哲学 在多Agent协作中，Agent拿到的上下文信息越少越好。若两个Agent需要频繁通信才能工作，说明最初的隔离边界划分错误。真正的多智能体效率源于严格的记忆和工具隔离，每个Agent只需在封闭环境中完成自身KPI，最后返回干净的最终摘要即可。 三、必须避开的反面模式 多个Agent协同编辑同一文件：即使修改不同功能块，也绝不能碰同一个文件。 滥用常规队列处理长任务：若用队列处理动辄半小时的长任务，会导致整个对话流被卡住，系统罢工。 指望delegate处理有逻辑依赖的子任务：子Agent被拉起时上下文清空，无法知晓其他Agent的工作，处理不了依赖关系。

相关文章