1. 多 Agent 协作到底在解决什么问题1.1 从单兵作战到团队配合的必然转变单个 Agent 处理任务时最典型的瓶颈就是上下文窗口和职责边界。你让一个 Agent 既做需求分析、又写代码、还负责测试和文档它很容易在中途“精神分裂”——前面刚确认好的接口规范写到后面就忘了或者把测试用例的逻辑混进了业务代码里。这不是模型能力不够而是单次推理的注意力资源被过度稀释了。多 Agent 协作的核心思路很朴素把一个大任务拆成若干个子任务每个子任务交给一个专门的 Agent 去处理Agent 之间通过明确的协议传递信息和结果。这就像一个小型研发团队有人负责需求拆解有人负责编码实现有人负责质量校验还有人负责集成和交付。每个角色只关注自己那一亩三分地反而能把事情做深做透。我最初接触多 Agent 是因为一个实际项目需要把一个遗留系统从旧框架迁移到新框架涉及几十个模块的代码改写、接口适配和回归测试。单 Agent 跑到第三个模块就开始出现上下文溢出改出来的代码风格前后不一致甚至把已经迁移好的模块又改回了旧写法。后来改成三个 Agent 分工——一个负责读取旧代码并生成迁移方案一个负责按方案写新代码一个负责对比新旧行为并跑测试——整个流程才稳定下来。1.2 多 Agent 协作的典型应用场景多 Agent 协作不是万能药它最适合以下几类场景长流程任务任务步骤超过 10 步且步骤之间有依赖关系比如从需求文档到可运行代码的完整交付。多角色任务需要不同专业视角参与比如代码生成需要“开发者视角”代码审查需要“安全视角”文档撰写需要“用户视角”。高可靠性要求单个 Agent 容易产生幻觉多个 Agent 交叉验证可以显著降低错误率。可并行任务子任务之间没有强依赖可以同时推进比如同时生成多个模块的单元测试。反过来如果你的任务很简单比如“把这段 JSON 转成 YAML”那单 Agent 一句话就搞定了硬上多 Agent 只会增加协调开销和出错概率。我见过不少团队为了“赶时髦”把简单任务拆成多 Agent结果调试成本比直接写代码还高。1.3 协作模式的核心分类目前主流的多 Agent 协作模式可以归纳为三类协作模式核心机制适用场景典型框架流水线模式Agent 按固定顺序执行前一个的输出是后一个的输入步骤明确、依赖关系固定的任务LangChain LCEL交接模式Agent 根据当前状态动态决定下一个由谁处理需要动态路由的任务如客服分流Swarm、AutoGen辩论模式多个 Agent 对同一问题给出方案通过投票或评审选出最优高可靠性要求的决策任务多 Agent 辩论框架我个人的经验是交接模式Handoff在工程实践中最为灵活因为它允许 Agent 在运行过程中根据实际情况调整下一步动作而不是死板地按照预设流程走。后面我会重点展开讲 Handoff 的实现细节。2. 协作 Skill 的设计与核心机制2.1 什么是协作 SkillSkill 这个词在不同语境下含义不同。在这里我把它定义为一组可复用的协作能力封装——包括角色定义、通信协议、状态管理、错误处理等。你可以把它理解为一个“协作工具箱”里面装着让多个 Agent 能够顺畅配合的所有基础设施。一个完整的协作 Skill 通常包含以下组件角色注册表定义每个 Agent 的名称、职责、可用工具和输入输出格式。消息总线Agent 之间传递信息的通道支持同步和异步两种模式。状态存储记录当前任务进展、已完成步骤、待处理事项。路由决策器根据当前状态决定下一个由哪个 Agent 接手。异常处理器当某个 Agent 失败或输出不符合预期时的回退策略。我自己的协作 Skill 是基于一个简单的 JSON 配置文件驱动的每个 Agent 的定义大概长这样{ name: code_reviewer, role: 代码审查员, description: 负责检查代码是否符合规范、是否存在安全漏洞, tools: [read_file, search_code, run_linter], input_schema: { code_path: string, review_focus: string }, output_schema: { issues: array, severity: string, suggestions: array } }这种声明式的定义方式好处很明显新增一个 Agent 只需要加一段配置不需要改核心调度逻辑。我在实际项目中从 3 个 Agent 扩展到 7 个 Agent核心代码一行没动只是往配置里追加了新的角色定义。2.2 Handoff 机制的实现细节Handoff 是多 Agent 协作中最关键的机制。它的核心问题是当前 Agent 完成任务后怎么知道下一步该交给谁最简单的做法是硬编码路由规则比如“代码写完后总是交给测试 Agent”。但这种方式缺乏灵活性遇到异常情况就卡住了。更优雅的做法是让 Agent 自己决定下一步动作具体来说有三种实现方式第一种基于规则的 Handoff。在配置里写清楚“如果输出中包含status: success则交给 Agent B如果包含status: need_clarification则交给 Agent C”。这种方式适合流程相对固定的场景调试起来也最直观。第二种基于模型的 Handoff。让当前 Agent 在输出中附带一个next_agent字段由模型自己判断该交给谁。这种方式灵活度高但需要给模型足够的上下文信息否则容易做出错误决策。我的做法是在系统提示词里明确列出所有可选的下游 Agent 及其职责并给出几个路由示例。第三种基于外部编排器的 Handoff。由一个独立的编排器 Agent 负责监听所有消息根据全局状态决定路由。这种方式适合复杂流程但编排器本身可能成为瓶颈。我实际采用的是混合模式常规步骤用规则路由异常情况交给编排器决策。这样既保证了主流程的稳定性又保留了处理意外的灵活性。2.3 上下文变量的传递与管理多 Agent 协作中最容易出问题的地方就是上下文传递。每个 Agent 都有自己的上下文窗口如果每次交接都把全部历史记录传过去很快就会撑爆。我的做法是维护一个共享上下文变量池只传递必要的状态信息。具体来说上下文变量分为三类全局变量所有 Agent 都能读取比如项目根目录、代码规范版本、当前迭代目标。角色变量只有特定 Agent 能读写比如代码审查员的检查清单。临时变量只在一次 Handoff 中有效比如“当前正在处理的文件路径”。在实现上我用一个简单的键值存储来管理这些变量每个变量带有作用域标记。Agent 在输出时只需要声明“我更新了哪些变量”编排器会自动合并到全局状态中。这样每个 Agent 拿到的上下文都是精简且相关的不会出现信息过载。注意上下文变量的命名一定要有统一规范比如用global.、role.、temp.前缀区分作用域。我早期没注意这一点结果两个 Agent 用了同名的临时变量导致状态互相覆盖排查了半天才发现。3. 从零搭建多 Agent 协作流程3.1 环境准备与基础配置搭建多 Agent 协作环境第一步是选一个支持多 Agent 调度的框架。目前可选的有 Swarm、AutoGen、CrewAI 等。我选的是 Swarm原因很简单它的 Handoff 机制最轻量核心代码只有几百行出了问题容易调试不像某些框架封装了十几层抽象报错信息根本看不懂。安装过程很直接pip install swarm-agent然后创建一个基础配置文件agents.yaml定义你的 Agent 团队agents: - name: planner role: 任务规划师 system_prompt: | 你负责将用户需求拆解为可执行的子任务列表。 输出格式为 JSON 数组每个任务包含 id、description、assigned_to 字段。 tools: - read_file - write_file - name: coder role: 代码实现者 system_prompt: | 你根据任务描述编写代码确保符合项目规范。 完成后输出 status: done 和文件路径。 tools: - read_file - write_file - run_command - name: reviewer role: 代码审查员 system_prompt: | 你检查代码的正确性、安全性和规范性。 发现问题时输出 status: issues_found 和问题列表。 没有问题则输出 status: approved。 tools: - read_file - search_code这个配置文件就是整个协作系统的“宪法”所有 Agent 的行为都从这里派生。我建议把配置文件纳入版本管理每次调整都记录变更原因方便回溯。3.2 定义 Agent 角色与职责边界角色定义最忌讳的是职责重叠。我见过一个配置两个 Agent 的提示词里都写了“负责检查代码质量”结果它们互相推诿都等着对方先动手。正确的做法是给每个 Agent 划定清晰的边界规划师只负责拆解任务不碰代码。实现者只负责写代码不做架构决策。审查员只负责找问题不直接改代码。集成者只负责合并和运行不判断代码好坏。边界清晰之后Handoff 的路由逻辑也变得简单规划师完成后必然交给实现者实现者完成后必然交给审查员审查员发现问题则退回给实现者审查通过则交给集成者。整个流程像一条生产线每个工位只做自己那道工序。我在实际项目中还加了一个协调者角色专门处理“审查员和实现者意见不一致”的情况。比如审查员认为某段代码有安全风险实现者认为那是误报双方僵持不下时协调者介入做最终裁决。这个角色不需要写代码只需要理解双方论点并给出判断。3.3 消息协议与数据格式约定Agent 之间的通信必须遵循统一的格式否则解析起来会非常痛苦。我的做法是强制所有 Agent 的输出都包含一个 JSON 块格式如下{ status: success | need_help | issues_found | approved, next_agent: coder | reviewer | integrator | null, context_updates: { global.current_file: src/main.py, temp.review_round: 2 }, payload: { message: 人类可读的说明, data: {} } }这个格式的好处是编排器只需要解析status和next_agent两个字段就能完成路由不需要理解payload里的具体内容。context_updates则用于更新共享状态保证下一个 Agent 拿到的是最新上下文。提示status字段的取值一定要提前枚举清楚不要允许 Agent 自由发挥。我早期没做限制结果某个 Agent 输出了status: maybe done编排器直接懵了整个流程卡死。3.4 启动与调试协作流程配置写好后启动流程只需要几行代码from swarm import Swarm, Agent client Swarm() planner Agent(nameplanner, instructions...) coder Agent(namecoder, instructions...) reviewer Agent(namereviewer, instructions...) def transfer_to_coder(): return coder def transfer_to_reviewer(): return reviewer planner.functions [transfer_to_coder] coder.functions [transfer_to_reviewer] response client.run( agentplanner, messages[{role: user, content: 实现一个用户登录接口}] )调试阶段我强烈建议开启详细日志把每次 Handoff 的输入输出都打印出来。我用的日志格式是[2024-01-15 10:23:45] planner - coder context: {global.task_id: T001, temp.plan: [...]} output: {status: success, next_agent: coder, ...}这样一旦流程卡住翻日志就能快速定位是哪个环节出了问题。我遇到过最常见的问题是 Agent 输出了不符合格式的 JSON导致解析失败。解决办法是在系统提示词里加一句“输出必须是合法的 JSON不要包含任何额外文字”并且在编排器里加一层容错解析。4. 实战中的常见问题与排查技巧4.1 Agent 之间互相等待导致死锁这是多 Agent 协作中最经典的问题。表现是流程运行到某一步后突然停住日志显示两个 Agent 都在等待对方先行动。根本原因通常是职责边界模糊或者 Handoff 条件没有覆盖所有情况。排查思路先看日志里最后一次成功的 Handoff 是什么然后检查当前 Agent 的输出是否包含明确的next_agent字段。如果没有说明它的提示词里缺少路由指令。如果有但指向了一个不存在的 Agent说明配置里的名称写错了。我的预防措施是在编排器里加一个超时机制如果某个 Agent 在 30 秒内没有产生有效输出就自动触发回退流程把控制权交给协调者。协调者会检查当前状态并决定是重试、跳过还是终止。4.2 上下文丢失导致重复劳动另一个高频问题是上下文传递不完整。比如实现者写完了代码审查员却不知道代码在哪个文件里只能重新问一遍。这通常是因为context_updates没有正确合并或者变量作用域设置错了。我的做法是在每个 Agent 的输入里强制包含一个context_snapshot字段列出当前所有可用的全局变量和角色变量。Agent 在输出时必须声明它读取了哪些变量、更新了哪些变量。编排器会校验这些声明如果发现某个 Agent 使用了未声明的变量就发出警告。4.3 输出格式不一致导致解析失败不同 Agent 对输出格式的理解可能有偏差。比如规划师输出的任务列表是 JSON 数组实现者却期望是 Markdown 表格。这种问题在 Agent 数量增多后会越来越频繁。解决方案是建立一个共享的 Schema 注册表所有 Agent 的输入输出格式都从这里引用。比如schemas: task_list: type: array items: type: object properties: id: {type: string} description: {type: string} assigned_to: {type: string}Agent 的配置里只需要写input_schema: task_list编排器会自动做格式校验和转换。这样即使某个 Agent 的输出格式有细微偏差也能被及时发现并纠正。4.4 常见问题速查表问题现象可能原因排查方法解决方案流程卡住不动Handoff 条件未覆盖检查最后一条日志的 next_agent补充路由规则或加超时回退Agent 重复问同样的问题上下文未正确传递检查 context_updates 是否合并修复变量作用域或合并逻辑输出解析失败格式不符合约定打印原始输出对比 Schema加强提示词约束或加容错解析Agent 之间互相推诿职责边界模糊检查各 Agent 的 system_prompt重新划分职责明确唯一负责人流程无限循环回退条件过于宽松统计 Handoff 次数设置最大重试次数超过则人工介入注意最大重试次数这个参数一定要设我一般设 3 次。超过 3 次还没解决说明问题不是 Agent 能处理的继续循环只是浪费 token。5. 协作 Skill 的扩展与优化5.1 动态增减 Agent 角色项目不同阶段需要的 Agent 角色可能不同。比如初期只需要规划师和实现者后期需要加入审查员和集成者。我的做法是把 Agent 定义做成插件式的每个 Agent 一个独立的配置文件编排器启动时扫描目录自动加载。这样新增一个 Agent 只需要在agents/目录下放一个新的 YAML 文件不需要改任何代码。删除 Agent 也一样把文件移走就行。这种设计让协作系统具备了很好的可扩展性我在不同项目之间切换时只需要替换agents/目录的内容。5.2 性能优化减少不必要的 HandoffHandoff 次数越多延迟越高token 消耗也越大。优化方向有两个一是合并可以并行执行的步骤二是减少不必要的确认环节。比如实现者写完代码后如果审查员只是做格式检查那完全可以把格式检查的逻辑内嵌到实现者的提示词里让实现者自己先过一遍。只有涉及安全性和逻辑正确性的审查才需要独立的审查员。我实测下来这样可以把 Handoff 次数减少 30% 左右整体耗时下降明显。另一个技巧是批量 Handoff如果实现者需要写 5 个文件不要每写完一个就交给审查员而是等 5 个都写完再一次性交接。这样审查员可以批量处理减少上下文切换的开销。5.3 可观测性建设日志与指标多 Agent 系统的调试难度比单 Agent 高一个数量级所以可观测性建设必须提前做。我主要关注三类指标Handoff 次数反映流程复杂度次数突然增加往往意味着出现了异常循环。每个 Agent 的平均处理时间找出瓶颈环节如果某个 Agent 耗时特别长可能需要优化它的提示词或工具配置。失败率按 Agent 统计输出解析失败、超时、格式错误的次数定位最不稳定的环节。这些指标我用一个简单的 SQLite 数据库记录每次 Handoff 写一条记录然后用 SQL 查询做分析。不需要上复杂的监控系统够用就行。5.4 安全边界与权限控制多 Agent 系统里不同 Agent 的权限应该有所区别。比如实现者可以写文件、执行命令但审查员只应该读文件不应该有写权限。规划师则只需要读需求文档连代码都不需要碰。我的做法是在 Agent 配置里加一个permissions字段permissions: read_file: true write_file: false run_command: false network_access: false编排器在执行工具调用前会检查权限没有权限的操作直接拒绝并记录日志。这样即使某个 Agent 被提示词注入了恶意指令也无法执行危险操作。提示network_access这个权限我默认全部设为 false。多 Agent 协作场景下Agent 不需要访问外部网络开放这个权限只会增加风险。6. 一个完整的协作案例拆解6.1 案例背景自动化代码迁移我拿一个真实项目来演示整个协作流程。需求是把一个 Python 2 写的旧模块迁移到 Python 3同时保持功能不变。这个任务涉及语法转换、依赖替换、行为验证三个环节正好适合多 Agent 协作。我的 Agent 团队配置如下分析员读取旧代码识别 Python 2 特有的语法和库输出迁移清单。迁移员按照迁移清单逐项修改代码生成新版本文件。验证员对比新旧代码的行为运行测试用例确认迁移正确。协调员处理验证员和迁移员之间的争议做最终裁决。6.2 流程执行与关键节点记录流程启动后分析员首先读取了legacy_module.py输出了迁移清单{ status: success, next_agent: migrator, payload: { items: [ {line: 15, issue: print 语句, fix: 改为 print() 函数}, {line: 23, issue: dict.has_key(), fix: 改为 in 操作符}, {line: 47, issue: urllib2 导入, fix: 改为 urllib.request} ] } }迁移员拿到清单后逐项修改生成了legacy_module_py3.py。验证员随后运行了对比测试发现第 23 行的修改导致了一个边界情况的行为差异旧代码用has_key()时对None键返回False新代码用in操作符时对None键会抛出TypeError。验证员将问题退回给迁移员迁移员修改后再次提交验证员确认通过。整个流程共发生 5 次 Handoff耗时约 3 分钟比单 Agent 反复重试快了将近一倍。6.3 效果评估与改进方向这个案例中多 Agent 协作的优势体现在三个方面一是分析员和迁移员的职责分离让每个环节的输出更专注二是验证员的独立检查发现了单 Agent 容易忽略的边界情况三是协调员的介入机制避免了无限循环。改进方向也很明确分析员的迁移清单可以更详细比如加上“影响范围”和“风险等级”字段这样迁移员可以优先处理高风险项。另外验证员的测试用例目前是手工编写的后续可以加一个 Agent 专门负责生成测试用例进一步提高自动化程度。7. 我踩过的坑与实操心得7.1 不要过度设计初始版本我刚开始搞多 Agent 协作时恨不得把每个环节都拆成独立 Agent结果配置了 12 个角色Handoff 关系图画出来像蜘蛛网一样。实际跑起来后光是调试路由逻辑就花了两天最后发现其中 5 个 Agent 的职责完全可以合并。现在的做法是从 3 个 Agent 起步一个负责规划一个负责执行一个负责检查。跑通之后再根据实际瓶颈决定是否拆分。大多数任务 3 个 Agent 就够了超过 5 个 Agent 的配置我基本都会重新审视是否有必要。7.2 提示词要写“约束”而不是“期望”早期我写提示词喜欢用“希望你能够……”、“尽量……”结果 Agent 的行为非常不稳定。后来改成硬性约束“你必须输出合法的 JSON”、“你只能读取文件不能写入”、“如果发现任何不确定的情况必须输出 status: need_help”。约束式提示词的效果立竿见影输出格式错误率从 30% 降到了 5% 以下。核心原则是不要给 Agent 留自由发挥的空间每个决策点都要有明确的规则。7.3 日志要记录“为什么”而不只是“是什么”普通的日志记录“Agent A 把任务交给了 Agent B”但这对调试帮助有限。真正有用的是记录“Agent A 为什么决定交给 Agent B”——是规则触发的还是模型判断的还是超时回退的。我在日志里加了一个decision_reason字段取值包括rule_match、model_choice、timeout_fallback、error_recovery。这样排查问题时一眼就能看出是配置问题还是模型问题。比如如果大量 Handoff 的decision_reason都是timeout_fallback说明某个 Agent 的响应太慢需要优化。7.4 定期清理无效的上下文变量上下文变量池如果不定期清理会越积越多最终拖慢整个系统。我的做法是每次任务完成后自动清理所有temp.前缀的变量只保留global.和必要的role.变量。另外每周做一次全量审计把超过 7 天没有被任何 Agent 读取的变量标记为“待清理”确认无用后删除。这个习惯帮我避免了一次严重事故有个临时变量存了一个大文件的完整内容任务结束后没清理后续每次 Handoff 都带着这个变量token 消耗直接翻倍。清理之后同样的任务耗时从 8 分钟降到了 4 分钟。7.5 给每个 Agent 设置“退出条件”Agent 最容易犯的错误是“过度努力”——明明任务已经完成了还在继续找事情做。比如审查员已经确认代码没问题了又去检查注释格式然后提出一堆无关紧要的建议导致流程反复。解决办法是在每个 Agent 的提示词里明确写出退出条件“当你确认以下所有条件都满足时立即输出 status: approved 并结束不要再做任何额外检查。”这个简单的改动让我的流程平均 Handoff 次数从 7 次降到了 4 次。8. 后续可以怎么扩展8.1 引入 Agent 能力评估机制目前我的协作系统里所有 Agent 的权重是一样的。但实际上不同 Agent 的可靠性有差异比如审查员的准确率可能只有 80%而验证员的准确率有 95%。后续可以给每个 Agent 加一个“可信度评分”在出现争议时优先采纳高可信度 Agent 的意见。评分可以基于历史数据自动计算每次 Agent 的输出被最终采纳还是被推翻都记录下来用滑动窗口计算近期准确率。这样系统会逐渐学会“更相信谁”。8.2 支持跨项目复用 Agent 配置现在每个项目的 Agent 配置是独立的但很多角色其实是通用的比如代码审查员、文档撰写员。后续可以把这些通用角色抽出来做成一个共享库新项目直接引用只需要覆盖差异化的部分。实现方式是用 YAML 的锚点anchor和合并merge功能reviewer: : *common_reviewer system_prompt: | 你负责审查这个项目的代码特别关注 XXX 规范。这样既保持了配置的灵活性又避免了重复定义。8.3 探索人机混合协作模式完全自动化的多 Agent 协作适合标准化任务但遇到需要人类判断的环节还是得有人参与。后续我想加一个“人类 Agent”角色在关键决策点暂停流程等待人工确认后再继续。比如代码迁移完成后是否直接合并到主分支这个决策可以交给人类。系统只需要在 Handoff 到“人类 Agent”时发送通知人类通过一个简单的界面确认或拒绝流程再继续往下走。这样既保留了自动化的效率又增加了关键环节的可控性。8.4 建立 Agent 行为的回归测试集每次调整 Agent 的提示词或配置都可能影响它的行为。为了保证改动不会引入退化需要一套回归测试集。我的想法是收集一批典型任务记录当前 Agent 的输出作为基线每次改动后重新跑一遍对比输出差异。差异不一定是坏事但必须经过人工审查确认是改进而不是退化。这个测试集不需要很大20 到 30 个典型场景就足够覆盖大部分边界情况。关键是持续维护每次发现新的边界情况就加进去让测试集越来越完善。提示回归测试集的基线输出要定期更新否则随着项目演进旧基线会变得不再适用导致大量误报。我一般每个月重新生成一次基线。8.5 优化 Token 消耗的策略多 Agent 协作的 Token 消耗是单 Agent 的数倍优化空间很大。除了前面提到的减少 Handoff 次数和清理上下文变量还有几个实用技巧压缩历史消息每次 Handoff 时只传递最近 3 轮对话的摘要而不是完整历史。按需加载工具定义Agent 不需要用到所有工具时只加载它实际需要的工具定义减少提示词长度。缓存重复计算如果多个 Agent 需要读取同一个文件第一次读取后缓存内容后续直接从缓存取。我实测下来这几个优化加起来可以降低 40% 左右的 Token 消耗对于长期运行的任务来说成本节省非常可观。8.6 探索更复杂的协作拓扑目前我的协作系统是链式拓扑A 交给 BB 交给 CC 交给 D。但有些任务更适合其他拓扑结构比如星型拓扑一个中心 Agent 负责调度其他 Agent 只和中心通信。适合任务拆分粒度细、需要频繁协调的场景。网状拓扑Agent 之间可以任意通信。适合需要多方协商的场景但调试难度最高。分层拓扑上层 Agent 负责规划下层 Agent 负责执行层内可以并行。适合大型项目可以同时处理多个子任务。我下一步想尝试分层拓扑把规划层和执行层分开执行层的多个 Agent 可以并行工作规划层负责汇总结果和决定下一步。这样理论上可以进一步提升效率但需要解决并行 Agent 之间的状态同步问题。8.7 建立 Agent 之间的信任机制在多 Agent 系统中Agent 之间的信任关系会影响协作效率。如果审查员总是不信任实现者的代码每个文件都要反复检查流程就会很慢。反过来如果审查员过于信任实现者又可能漏掉问题。我的想法是引入一个动态信任分数初始时所有 Agent 之间的信任分数都是中等每次协作后根据结果调整。如果实现者的代码被审查员发现问题实现者的信任分数下降如果审查员误报审查员的信任分数下降。信任分数影响 Handoff 时的检查强度——信任分数高时审查员可以快速通过信任分数低时审查员需要做更详细的检查。这个机制目前还在设计中核心难点是如何定义“误报”和“漏报”的判定标准。我打算先从简单的规则开始比如审查员提出的问题被协调员判定为无效就算一次误报。积累足够数据后再考虑用模型来自动判定。8.8 支持多模态 Agent 协作目前我的 Agent 都是处理文本的但实际项目中经常需要处理图片、图表、日志截图等多模态内容。后续可以引入支持多模态的 Agent比如一个专门负责“看截图找问题”的 Agent一个负责“生成架构图”的 Agent。多模态 Agent 的 Handoff 需要传递图片数据这对上下文变量的存储和传输提出了新要求。我初步的想法是把图片存到本地文件系统上下文变量里只存文件路径Agent 需要时再读取。这样既避免了上下文膨胀又保持了灵活性。8.9 构建 Agent 能力市场如果多 Agent 协作系统用久了会积累很多可复用的 Agent 配置。这些配置可以形成一个“能力市场”新项目直接从市场里挑选需要的 Agent像搭积木一样组合。市场里的每个 Agent 都带有详细的说明文档、输入输出示例、性能指标和用户评价。这样新项目的搭建成本会大幅降低不需要从零开始设计每个角色。我目前已经在团队内部做了一个简易版本把常用的 10 个 Agent 配置整理成了共享库新项目启动时直接引用节省了大量配置时间。8.10 探索自适应协作流程目前的协作流程是静态配置的Handoff 规则写死在配置文件里。但实际任务千变万化固定流程很难覆盖所有情况。后续想探索自适应流程系统根据任务特征自动选择最合适的协作拓扑和 Agent 组合。比如一个简单的代码格式化任务系统自动选择“实现者 - 审查员”的两步流程一个复杂的架构重构任务系统自动选择“分析员 - 规划员 - 实现者 - 审查员 - 验证员 - 协调员”的六步流程。选择逻辑可以基于任务描述的长度、涉及的文件数量、历史类似任务的成功率等特征。这个方向的技术难度较高但一旦做成协作系统的适用范围会大大扩展。我打算先从简单的规则引擎开始积累足够数据后再考虑用模型来做流程推荐。