企业官网建设流程全解析

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 协作模式可以归纳为三类：

我个人的经验是，交接模式（Handoff）在工程实践中最为灵活，因为它允许 Agent 在运行过程中根据实际情况调整下一步动作，而不是死板地按照预设流程走。后面我会重点展开讲 Handoff 的实现细节。

2. 协作 Skill 的设计与核心机制

2.1 什么是协作 Skill

Skill 这个词在不同语境下含义不同。在这里，我把它定义为一组可复用的协作能力封装——包括角色定义、通信协议、状态管理、错误处理等。你可以把它理解为一个“协作工具箱”，里面装着让多个 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(name="planner", instructions="...") coder = Agent(name="coder", instructions="...") reviewer = Agent(name="reviewer", 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( agent=planner, 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 常见问题速查表

注意：最大重试次数这个参数一定要设，我一般设 3 次。超过 3 次还没解决，说明问题不是 Agent 能处理的，继续循环只是浪费 token。

5. 协作 Skill 的扩展与优化

5.1 动态增减 Agent 角色

项目不同阶段需要的 Agent 角色可能不同。比如初期只需要规划师和实现者，后期需要加入审查员和集成者。我的做法是把 Agent 定义做成插件式的，每个 Agent 一个独立的配置文件，编排器启动时扫描目录自动加载。

这样新增一个 Agent 只需要在agents/目录下放一个新的 YAML 文件，不需要改任何代码。删除 Agent 也一样，把文件移走就行。这种设计让协作系统具备了很好的可扩展性，我在不同项目之间切换时，只需要替换agents/目录的内容。

5.2 性能优化：减少不必要的 Handoff

Handoff 次数越多，延迟越高，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 交给 B，B 交给 C，C 交给 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 组合。

比如一个简单的代码格式化任务，系统自动选择“实现者 -> 审查员”的两步流程；一个复杂的架构重构任务，系统自动选择“分析员 -> 规划员 -> 实现者 -> 审查员 -> 验证员 -> 协调员”的六步流程。选择逻辑可以基于任务描述的长度、涉及的文件数量、历史类似任务的成功率等特征。

这个方向的技术难度较高，但一旦做成，协作系统的适用范围会大大扩展。我打算先从简单的规则引擎开始，积累足够数据后再考虑用模型来做流程推荐。