1. 从"agency-agents"这个名字说起：一个被低估的架构命题

第一次看到agency-agents这个命名，我的直觉是：这不是一个普通的工具库，而是一个关于"代理组织化"的架构命题。agency在英文语境里指的是"代理机构、中介组织"，而agents是复数形式的"代理"。把这两个词拼在一起，它传递的核心信号非常明确——这不是单个代理的玩法，而是一群代理如何被组织、编排、协作、治理的系统性问题。

过去两年，我经手过不下十个多代理协作的项目，从最简单的"两个代理互相调用"到"十几个代理分层协作"，踩过的坑几乎可以写一本书。大多数人在接触多代理系统时，第一反应是"我要让代理做更多的事"，但真正跑起来之后才发现，难点从来不是单个代理有多聪明，而是多个代理之间如何不打架、不重复劳动、不互相甩锅。agency-agents这个标题恰好戳中了这个痛点——它暗示的是一套"代理机构"式的组织框架，而不是零散的代理堆砌。

这篇文章适合三类人看：第一类是想从单代理应用升级到多代理系统的开发者，你需要知道架构上会发生什么质变；第二类是已经在做多代理但被协作混乱折磨的工程师，你需要一套可落地的编排思路；第三类是对代理系统感兴趣、想理解其底层逻辑的技术爱好者，我会尽量用生活化的类比把复杂机制讲清楚。全文不会给你一个"复制粘贴就能跑"的万能模板，因为多代理系统本质上没有万能模板，但我会把设计决策背后的"为什么"讲透，让你能根据自己的场景做出合理取舍。

2. 代理组织化的核心矛盾：为什么"多代理"比"单代理"难十倍

2.1 单代理的舒适区与它的天花板

单个代理的工作模式其实很好理解：给它一个目标，它调用工具、推理、输出结果。就像一个全能型的自由职业者，什么活都自己干。这种模式在任务边界清晰、步骤不超过十步的场景下非常高效。我早期做过一个文档摘要代理，输入一篇长文，输出结构化摘要，整个链路就是"读取-分段-摘要-合并"，简单直接，几乎没有协调成本。

但单代理的天花板也很明显。当任务需要不同领域的专业知识时，一个代理要么被迫变成一个"什么都懂一点但什么都不精"的万金油，要么就得在提示词里塞进大量互相冲突的指令。我见过一个典型的失败案例：某团队试图用一个代理同时处理"代码审查"和"产品需求分析"，结果代理在审查代码时总是不自觉地跑偏去讨论需求合理性，在分析需求时又忍不住点评代码质量。这不是模型能力问题，而是角色冲突——一个人不可能同时是严格的代码审查员和发散的产品经理。

另一个天花板是上下文窗口的物理限制。当任务涉及大量文档、多轮交互、长链路推理时，单代理的上下文会被迅速填满，早期的关键信息被挤出窗口，导致"失忆"。这个问题在多代理架构下可以通过"分工+摘要传递"来缓解，因为每个代理只需要关注自己那部分上下文。

2.2 多代理带来的三个新问题

从单代理升级到多代理，你会立刻面对三个单代理时代不存在的问题。

第一个是通信问题。代理之间怎么传递信息？是传递完整的原始数据，还是传递摘要？如果传递完整数据，上下文会爆炸；如果传递摘要，摘要过程中丢失的关键细节可能导致下游代理做出错误决策。我在一个多代理研究项目里就吃过这个亏：上游的检索代理把十篇论文压缩成了一段两百字的摘要传给分析代理，结果分析代理因为看不到具体的实验数据，给出了一个完全错误的趋势判断。后来我们改成"摘要+关键数据表"的混合传递方式，才解决了这个问题。

第二个是职责边界问题。谁负责什么？如果边界不清，就会出现两个代理抢同一个任务，或者一个任务谁都不管。这就像公司里没有明确的岗位说明书，员工之间要么重复劳动，要么互相推诿。多代理系统里，职责边界通常通过角色定义和工具权限来划定——每个代理有明确的角色描述，只能访问特定的工具集。

第三个是失败处理问题。单代理失败了，重试就行。多代理系统里，一个代理失败可能引发连锁反应：下游代理拿到错误输入继续执行，最终产出一个看似合理实则错误的结果。更麻烦的是，你很难定位到底是哪个环节出了问题。我见过最离谱的情况是，一个五代理协作的系统产出了完全错误的报告，排查了整整两天才发现是第二个代理在某个边界条件下返回了空值，而第三个代理把空值当成了"无异常"继续往下传。

2.3 "代理机构"隐喻给我们的启示

agency-agents这个命名里的"agency"其实给了很好的启示。一家真实的代理机构是怎么运作的？它有明确的组织架构、有岗位职责、有汇报关系、有质量控制流程、有客户对接窗口。多代理系统的设计完全可以借鉴这套逻辑：

• 组织架构对应代理的层级关系（是扁平协作还是分层管理）
• 岗位职责对应每个代理的角色定义和工具权限
• 汇报关系对应代理之间的信息流向和决策权归属
• 质量控制对应结果验证和交叉检查机制
• 客户对接对应系统的输入输出接口设计

这个隐喻的价值在于，它把"技术问题"转化成了"组织问题"，而组织问题在人类社会中已经被研究了几千年，有大量成熟的经验可以迁移。下面这张表对比了单代理和多代理在几个关键维度上的差异，能帮你快速判断自己的场景该不该上多代理。

3. 拆解一个代理组织的骨架：角色、工具、记忆、编排四件套

3.1 角色定义：不是起个名字那么简单

很多人定义代理角色时，就是写一句"你是一个XX专家"。这在单代理场景下勉强够用，但在多代理系统里远远不够。一个合格的角色定义至少包含四个要素：专业领域、职责范围、行为准则、输出格式。

专业领域回答"这个代理懂什么"，比如"精通数据清洗和异常检测"。职责范围回答"这个代理负责哪些具体任务、不负责哪些任务"，这一步特别关键，因为它是防止职责重叠的第一道防线。行为准则回答"这个代理在遇到不确定情况时该怎么办"，比如"当数据缺失超过30%时，必须向上游代理请求补充而不是自行猜测"。输出格式回答"这个代理产出什么结构的数据"，这直接决定了下游代理能不能顺利消费。

我自己的经验是，角色定义写得越具体，后期调试越轻松。曾经有个项目，我把一个代理的角色写成"负责分析用户反馈"，结果它一会儿做情感分析，一会儿做主题聚类，一会儿又去统计词频，输出格式每次都不一样，下游代理苦不堪言。后来我把角色拆成三个独立代理，每个只做一件事，输出格式固定，整个系统立刻稳定了。角色定义的本质是约束，而约束恰恰是多代理系统稳定的前提。

3.2 工具权限：最小权限原则的工程实践

工具权限的设计要遵循最小权限原则——每个代理只能访问完成其职责所必需的工具，多一个都不给。这不是为了限制代理的能力，而是为了减少意外行为。

举个具体的例子。假设你有一个"数据检索代理"和一个"数据分析代理"。检索代理需要访问搜索工具和数据库查询工具，但不需要代码执行工具；分析代理需要代码执行工具和统计工具，但不需要搜索工具。如果你图省事给两个代理都开放了全部工具，会发生什么？检索代理可能在检索失败时"自作聪明"地写一段代码去爬数据，分析代理可能在分析卡壳时去搜索"如何做回归分析"，这些行为不仅低效，还可能引入不可控的风险。

工具权限的配置通常通过工具注册表来实现。每个代理在初始化时声明自己需要哪些工具，编排层根据声明进行权限校验。下面是一个简化的配置示例，用伪代码展示这个思路：

# 代理工具权限配置示例（伪代码） agent_configs = { "retrieval_agent": { "role": "负责从知识库和外部数据源检索相关信息", "tools": ["search", "database_query"], "forbidden_tools": ["code_executor", "file_writer"] }, "analysis_agent": { "role": "负责对检索结果进行统计分析和趋势判断", "tools": ["code_executor", "statistics"], "forbidden_tools": ["search", "database_query"] }, "report_agent": { "role": "负责将分析结果整理成结构化报告", "tools": ["file_writer", "template_engine"], "forbidden_tools": ["search", "code_executor"] } }

注意：工具权限的校验必须在编排层强制执行，不能只靠提示词约束。提示词是"建议"，编排层的校验才是"法律"。我见过太多项目只在提示词里写"你不要用XX工具"，结果代理在压力下照样违规调用。

3.3 记忆机制：短期、长期与共享记忆的分层设计

多代理系统的记忆比单代理复杂得多，因为它涉及"谁记得什么"和"谁能看到谁的记忆"。我通常把记忆分成三层：

短期记忆是单个代理在一次任务执行中的工作记忆，相当于人的"当前思考内容"。它不需要持久化，任务结束就清空。长期记忆是跨任务持久化的知识，比如历史处理过的案例、积累的经验规则。共享记忆是多个代理都能访问的公共信息区，比如任务的整体目标、当前进度、已产出的中间结果。

这三层记忆的设计直接影响到系统的效率和一致性。我踩过的一个坑是：早期我把所有信息都放在共享记忆里，结果每个代理都要读取大量与自己无关的信息，上下文被迅速占满，而且不同代理对同一份共享信息的理解还不一致。后来我改成"共享记忆只放全局状态和接口约定，具体数据通过点对点传递"，效率提升非常明显。

共享记忆的另一个关键问题是并发写入。当多个代理同时想更新共享记忆时，如果没有锁机制，就会出现覆盖丢失。我的做法是给共享记忆的每个字段加上版本号，写入时检查版本，版本不匹配就重试。这个机制虽然简单，但能避免绝大多数并发问题。

3.4 编排模式：流水线、辩论、层级，选哪个

编排模式决定了代理之间怎么协作。常见的模式有三种，各有适用场景。

流水线模式是最简单的：代理A的输出是代理B的输入，B的输出是C的输入，像工厂流水线一样。这种模式适合步骤明确、依赖关系线性的任务，比如"检索-分析-报告"三阶段。它的优点是逻辑清晰、容易调试，缺点是缺乏灵活性，一旦某个环节出问题，整条线都得停下来。

辩论模式是让多个代理对同一问题给出各自的观点，然后通过某种机制（比如投票、裁判代理）达成共识。这种模式适合需要多角度审视的任务，比如风险评估、方案评审。它的优点是能减少单一代理的偏见，缺点是成本高——同样的任务要跑好几遍。

层级模式是设置一个"管理者代理"来协调多个"工作者代理"。管理者负责拆解任务、分配工作、汇总结果，工作者负责执行具体任务。这种模式适合复杂任务，因为它能动态调整分工。缺点是管理者的设计很关键，如果管理者本身能力不足，整个系统就会瘫痪。

我个人的经验是，大多数项目从流水线模式起步就够了，不要一上来就搞层级模式。流水线跑通之后，如果发现某些环节确实需要动态调整，再逐步引入层级。过早引入复杂编排，只会让你在调试协作逻辑上耗费大量时间，而核心业务逻辑反而没时间打磨。

4. 让代理组织真正跑起来：通信协议与状态管理的实操细节

4.1 消息格式：结构化是底线，但别过度设计

代理之间的通信消息必须是结构化的，这一点没有商量余地。自然语言消息在简单场景下能跑，但一旦代理数量超过三个，自然语言消息的歧义性就会成为灾难。我见过一个项目，两个代理用自然语言通信，上游说"数据基本正常"，下游理解成"数据完全正常"，结果跳过了一个本该执行的校验步骤。

结构化消息的最小字段集包括：发送者、接收者、消息类型、负载、时间戳、关联任务ID。消息类型通常分为几类：任务请求、任务结果、状态更新、错误报告、控制指令。负载部分根据消息类型不同而不同，但建议用JSON或类似的结构化格式。

但结构化不等于过度设计。我早期犯过一个错误，设计了一套包含二十多个字段的消息格式，结果每个代理在发送消息时都要填一大堆字段，很多字段根本用不上，反而增加了出错概率。后来我精简到六个核心字段，其余信息放在负载里按需扩展，开发效率立刻上来了。消息格式的设计原则是：核心字段固定，扩展字段灵活。

4.2 同步与异步：什么时候该等，什么时候该放

代理之间的调用是同步还是异步，这个决策会深刻影响系统的性能和复杂度。

同步调用意味着调用方会阻塞等待被调用方返回结果。这种方式逻辑简单，容易理解，但会导致资源浪费——调用方在等待期间什么都做不了。异步调用则允许调用方继续处理其他事情，等被调用方完成后通过回调或轮询获取结果。这种方式效率高，但逻辑复杂，调试困难。

我的建议是：关键路径上的调用用同步，非关键路径用异步。什么是关键路径？就是那些"没有它的结果，后续步骤无法进行"的调用。比如检索代理必须先返回结果，分析代理才能开始工作，这就是关键路径，用同步。而那些"可以并行处理、结果晚点到也不影响整体进度"的调用，比如日志记录、辅助校验，用异步。

还有一个容易被忽略的点是超时处理。同步调用必须设置超时，否则一个卡住的代理会拖垮整个系统。超时时间设多长？我的经验是设为该代理平均响应时间的三倍。如果平均响应是5秒，超时就设15秒。超时后怎么办？通常是重试一次，如果还失败就降级处理——要么跳过这个步骤，要么用默认值替代。

4.3 状态一致性：分布式系统的老问题在新场景下的表现

多代理系统本质上是一个分布式系统，所以它会继承分布式系统的所有经典问题，其中最难的就是状态一致性。

想象一个场景：任务状态存储在共享记忆里，代理A把状态从"进行中"改成"已完成"，代理B同时把状态从"进行中"改成"失败"。如果没有一致性机制，最终状态取决于谁后写入，而先写入的那个状态就丢失了。这在任务编排中是致命的——如果"已完成"被"失败"覆盖，系统会错误地重试一个已经完成的任务；如果"失败"被"已完成"覆盖，系统会错误地认为任务成功，跳过必要的错误处理。

解决状态一致性的常见方案有三种。乐观锁是最轻量的：每次写入时检查版本号，版本不匹配就重试。它适合冲突概率低的场景。悲观锁是写入前先加锁，写完释放，适合冲突概率高的场景，但会降低并发度。事件溯源是不直接修改状态，而是记录所有状态变更事件，通过重放事件来推导当前状态。这种方式最复杂，但可追溯性最强，适合对审计要求高的场景。

我在实际项目中用得最多的是乐观锁，因为它实现简单、性能好，而且多代理系统的状态冲突其实没有想象中那么频繁——只要你的职责边界划得清楚，大部分时候代理们操作的是不同的状态字段。

4.4 一个完整的通信流程示例

为了让你对通信流程有具体的感知，我描述一个典型的"检索-分析-报告"三代理流水线的完整通信过程。

任务开始，编排层创建任务ID，初始化共享记忆，把任务目标写入。检索代理收到任务请求，调用搜索工具，拿到原始数据，做初步清洗，把结果以结构化消息发给分析代理，同时更新共享记忆里的任务状态为"检索完成"。分析代理收到数据，调用代码执行工具做统计分析，生成分析结果，发给报告代理，更新状态为"分析完成"。报告代理收到分析结果，调用模板引擎生成报告，写入文件，更新状态为"全部完成"。编排层检测到状态变为"全部完成"，收集最终产出，返回给调用方。

这个流程看起来简单，但每个环节都有细节。比如检索代理在清洗数据时发现数据质量不达标怎么办？它应该发一条"数据质量告警"消息给编排层，编排层决定是继续还是终止。再比如分析代理的代码执行超时了怎么办？它应该捕获超时异常，发一条"分析失败"消息，编排层决定是重试还是降级。这些异常路径的处理，才是多代理系统真正的工作量所在。

5. 那些只有踩过才知道的坑：多代理协作的故障排查实录

5.1 无限循环：代理A等代理B，代理B等代理A

这是多代理系统最经典的死锁场景。代理A的任务依赖代理B的输出，代理B的任务又依赖代理A的输出，两者互相等待，系统卡死。

我遇到过一次真实案例：一个"需求分析-方案设计"的双代理系统，需求分析代理在分析到一半时发现需要方案设计代理提供技术可行性评估，于是发了一条请求；方案设计代理在评估可行性时发现需求描述不够清晰，又发了一条请求给需求分析代理要求补充。两条请求互相等待，系统挂了整整一个下午才被发现。

解决这个问题的核心是打破循环依赖。具体做法有几种：一是设置超时，任何代理等待超过阈值就放弃等待，返回部分结果或报错；二是引入"仲裁者"，当检测到循环依赖时，由仲裁者决定先满足哪一方的请求；三是在设计阶段就避免循环依赖，通过分层设计确保信息只从上游流向下游。

提示：在设计代理依赖关系时，画一张依赖图，如果图中有环，就说明存在循环依赖风险。这张图应该成为你架构设计文档的必备内容。

5.2 信息衰减：经过三个代理后，原始信息还剩多少

信息在代理之间传递时会衰减，这是我在多个项目中反复验证的规律。假设每个代理在传递信息时会丢失10%的细节，经过三个代理后，原始信息只剩70%左右。如果每个代理丢失20%，三个代理后就只剩50%了。

信息衰减的后果是下游代理基于不完整的信息做出错误决策。我见过最严重的一次，原始数据里有一个关键的异常值，经过检索代理的摘要、分析代理的归纳、报告代理的提炼，这个异常值被彻底"洗掉"了，最终报告呈现的是一个完全正常的结论，而实际上数据里藏着一个重大风险信号。

对抗信息衰减的手段有三个。一是关键信息冗余传递：对于特别重要的信息，不依赖摘要传递，而是原样传递，哪怕会增加上下文负担。二是设置信息校验点：在关键节点上，让下游代理反向确认"我收到的信息是否完整"，如果发现缺失就向上游请求补充。三是保留原始数据引用：代理传递的不是数据本身，而是数据的引用（比如存储位置），下游代理需要时可以回溯原始数据。

5.3 责任扩散：三个代理都以为别人会处理

这是组织行为学里"责任扩散"现象在代理系统里的翻版。当多个代理都能处理某个异常时，往往没有一个代理去处理，因为每个代理都以为别人会处理。

我遇到过一个案例：数据校验失败，检索代理认为"这是分析代理该处理的"，分析代理认为"这是检索代理该处理的"，报告代理认为"这不关我的事"，结果这个校验失败被无声无息地忽略了，最终产出了一份基于错误数据的报告。

解决责任扩散的关键是明确异常归属。每个异常类型都必须指定一个"负责人代理"，这个代理有义务处理或上报该异常。如果异常类型没有对应的负责人，编排层应该捕获并报警，而不是让它悄悄溜过去。我的做法是在编排层维护一张"异常-负责人"映射表，任何未被处理的异常都会触发告警。

5.4 性能瓶颈：不是代理慢，是协调慢

很多人优化多代理系统性能时，第一反应是优化单个代理的推理速度。但实际测下来，协调开销往往才是真正的瓶颈。

我做过一次性能剖析，一个五代理系统的总耗时中，单个代理的推理时间只占40%，剩下60%都花在了消息传递、状态同步、权限校验、日志记录这些协调操作上。这意味着，即使你把每个代理的推理速度提升一倍，总耗时也只能降低20%。

优化协调开销的手段包括：减少不必要的消息传递（能合并的消息就合并）、用异步替代同步（非关键路径）、缓存频繁访问的状态（避免重复查询）、简化权限校验逻辑（用位运算替代复杂的规则匹配）。这些优化看起来不起眼，但累积起来效果显著。我在一个项目里通过合并消息和引入状态缓存，把总耗时降低了35%，而单个代理的逻辑一行没改。

6. 从能跑到好用：代理组织的可观测性与持续优化

6.1 日志与追踪：让每一次代理调用都有迹可循

多代理系统如果没有完善的日志和追踪，调试就是一场噩梦。你看到的是"最终结果错了"，但不知道错在哪个环节。所以从第一天起就要建立追踪机制。

追踪的核心是任务ID贯穿全链路。每个任务从创建时分配一个唯一ID，这个ID会出现在所有相关的日志、消息、状态记录中。当出现问题时，你可以通过任务ID拉出完整的执行链路，看到每个代理的输入、输出、耗时、状态变更。

除了任务ID，还建议记录代理调用图——哪个代理调用了哪个代理、调用顺序是什么、每次调用的耗时是多少。这张图能帮你快速定位性能瓶颈和异常路径。我用过的一个简单方案是把调用关系输出成缩进文本，虽然简陋但非常直观：

[任务T-1024] 总耗时 12.3s ├─ 检索代理 (3.2s) │ ├─ 搜索工具 (1.8s) │ └─ 数据库查询 (1.4s) ├─ 分析代理 (6.5s) │ ├─ 代码执行 (5.1s) │ └─ 统计计算 (1.4s) └─ 报告代理 (2.6s) └─ 模板渲染 (2.6s)

6.2 评估指标：怎么判断一个代理组织是"健康"的

判断多代理系统是否健康，不能只看"任务是否完成"，还要看一组综合指标。我常用的指标包括：

任务成功率是最基础的，但要区分"完全成功"和"部分成功"。平均耗时要分环节统计，找出瓶颈。重试率反映系统的稳定性，重试率过高说明某些环节不可靠。异常分布能告诉你哪类问题最频繁。信息衰减率通过对比原始输入和最终输出，评估信息在传递过程中的损失程度。协调开销占比是协调耗时占总耗时的比例，这个比例过高说明编排设计有问题。

这些指标不需要一开始就全部建立，但至少要有任务成功率和平均耗时。等系统跑稳定了，再逐步补充其他指标。我见过一些团队一上来就搭建复杂的监控体系，结果指标太多反而没人看，最后沦为摆设。

6.3 迭代策略：先固化再优化，别过早追求完美

多代理系统的迭代，我的建议是先固化再优化。所谓固化，就是把协作流程、消息格式、角色定义这些基础框架稳定下来，哪怕它们不完美。所谓优化，是在框架稳定的基础上，逐步调整细节。

为什么不能一开始就追求完美？因为多代理系统的很多问题只有在实际运行中才会暴露。你在设计阶段觉得天衣无缝的协作流程，跑起来可能发现某个环节根本走不通；你觉得合理的消息格式，实际用起来可能发现缺了关键字段。如果一开始就追求完美，你会陷入无休止的设计-推翻-再设计的循环。

我的做法是：第一版用最简框架跑通端到端流程，哪怕每个代理都很"笨"、消息格式很粗糙。跑通之后，收集实际运行中的问题，按优先级逐个优化。每次优化只改一个点，改完验证效果，确认没问题再改下一个。这种小步快跑的方式，比大重构稳妥得多。

6.4 一个真实的优化案例：从12秒到4秒

最后分享一个我实际做过的优化案例，虽然具体数字做了模糊处理，但优化思路是真实的。

一个三代理流水线系统，初始版本端到端耗时约12秒。剖析后发现：检索代理3秒，分析代理6秒，报告代理2秒，协调开销1秒。看起来分析代理是瓶颈，但深入看发现，分析代理的6秒里有4秒是在等待检索代理的数据传输完成——因为数据传输是同步的，而且传的是完整原始数据。

优化分三步。第一步，把数据传输改成"摘要+引用"模式，分析代理先拿到摘要开始工作，需要细节时再按引用拉取，这一步省了2秒。第二步，把报告代理的模板渲染改成异步，在分析代理还在收尾时就开始预渲染，省了1秒。第三步，给检索代理的搜索结果加缓存，相同查询直接命中缓存，省了1.5秒。三步下来，总耗时从12秒降到约4秒，而且没有改动任何代理的核心逻辑。

这个案例的启示是：多代理系统的性能优化，重点往往不在代理本身，而在代理之间的协作方式。先优化协作，再优化个体，投入产出比高得多。

7. 关于代理组织化，我个人的几点体会

做多代理系统这两年，最大的体会是：技术问题到最后都是组织问题。代理之间的协作混乱，本质上和人类团队协作混乱的原因是一样的——职责不清、沟通不畅、缺乏仲裁、没有复盘。所以我在设计多代理系统时，经常问自己一个奇怪的问题："如果这是一家公司，我会怎么设计它的组织架构？"这个问题往往能帮我找到更合理的代理编排方案。

另一个体会是克制。多代理很酷，但不是所有场景都需要多代理。我见过太多项目，明明单代理就能搞定，非要拆成三四个代理，结果复杂度上去了，效果反而下降了。判断标准很简单：如果任务不需要多领域知识、不需要并行处理、上下文不会溢出，那就老老实实用单代理。多代理是解决特定问题的工具，不是炫技的手段。

最后一个体会是可观测性优先。多代理系统一旦出问题，排查难度是单代理的数倍。所以我在项目初期就会把日志、追踪、指标这些基础设施搭好，哪怕功能还没开发完。这些投入在后期会以数倍的方式回报你——当别人还在靠打印日志猜问题的时候，你已经通过追踪链路直接定位到根因了。

如果你正在考虑上多代理系统，我的建议是：先用单代理跑通业务逻辑，确认业务价值；然后找出单代理的真正瓶颈（是能力不足还是上下文限制）；如果确实是上下文限制，再考虑拆分成多代理。拆分时从最简单的流水线模式开始，把角色定义、工具权限、消息格式这三样基础打好，剩下的就是迭代优化的事了。