简介：在企业 AI Agent 架构中，按业务拆分子 Agent 并不总能带来效率提升，反而可能因上下文传递、摘要生成和串行等待增加延迟。本文对比“多子 Agent 协作”与“主 Agent 配合 Skills 与工具”两种架构，从交接成本、上下文共享、性能、运维和适用场景等维度分析差异，帮助技术团队判断何时应合并子 Agent、何时保留拆分，并给出可落地的选型建议与迁移注意事项。
在构建企业级智能客服、内部业务助手或自动化工作流时，一种常见做法是按业务域拆分多个专家子 Agent。例如，智能客服系统里可能同时存在订单查询、配送查询、退款处理、会员权益等多个子 Agent，每个子 Agent 由不同业务团队维护，拥有独立的提示词、工具集和上下文。用户请求进入后，由主 Agent 负责理解意图、路由任务、汇总结果。
从表面看，这种架构职责清晰、边界明确：每个团队维护自己的业务逻辑，互不干扰；平台团队只需做一层编排。但在实际部署中，不少团队发现用户体验反而下降：响应变长、口径不统一、同一信息被反复询问。问题并不在于“拆分”本身，而在于拆分的方式是否匹配真实执行链路。
本文对比的是两种 Agent 组织方式：
方案 A：多子 Agent 协作架构
主 Agent 作为协调者，将任务委派给多个业务子 Agent。每个子 Agent 拥有独立上下文，通过接收任务说明、执行操作、返回摘要与主 Agent 交互。
方案 B：主 Agent + Skills 与工具架构
将部分业务规则、流程步骤封装为 Skills，将数据查询、状态变更等操作封装为工具，由一个主 Agent 直接调用。主 Agent 保持统一上下文，不再将任务“移交”给另一个独立 Agent。
需要说明的是，Skills 并不是将子 Agent 简单降级为函数。它更像一种“可被主 Agent 按需加载和执行的业务能力模块”，承载“该怎么做”的规则；而工具承载“能做什么”的具体操作。两者的组合让主 Agent 在不丢失业务语义的前提下，减少跨 Agent 交接。
两种方案在目标层面高度一致：
因此，这不是“正确与错误”的对立，而是“在不同边界条件下如何组织执行单元”的选择。
这是两种方案最根本的差异。
多子 Agent 架构：主 Agent 委派任务时，需要将用户背景、已知条件、历史查询结果等重新组织成一段委派说明。子 Agent 收到的是“二手上下文”，并不自动知道此前发生过什么。子 Agent 完成后，再将结果压缩成摘要返回。如果后续还要找另一个子 Agent，主 Agent 又得决定哪些信息值得继续传递。
主 Agent + Skills 架构：主 Agent 始终维护一份执行上下文。调用某个 Skill 或工具时，它可以直接使用当前上下文中已有的数据，无需重新说明背景。前一个步骤查询到的结果，后续步骤可直接引用，不必生成中间摘要再传递。
这一差异直接影响了信息完整性：摘要天然有损，任何未被摘要覆盖的细节都可能成为后续步骤的盲区。
多子 Agent 串行协作时，延迟通常来自以下几个方面：
当两个子 Agent 存在强依赖关系时，例如“查订单”必须拿到前一个“查会员等级”返回的折扣规则才能计算运费，这种串行开销更加明显。后一个子 Agent 必须等前一个完全结束，且只能拿到前者的摘要输出。
主 Agent + Skills 方案中，这些交接环节被压缩。主 Agent 直接按顺序调用 Skill 和工具，中间结果保存在同一上下文里，省去了“委派—摘要—再委派”的循环。需要强调的是，如果业务本身就要串行执行，无论哪种方案都无法消除业务上的串行时间；但主 Agent + Skills 至少可以消除因架构引入的额外交接时间。
多个子 Agent 由不同团队维护时，各自的提示词风格、回复模板、术语表达可能不同。用户在一个会话中可能先收到订单子 Agent 的回复，再收到配送子 Agent 的回复，两者口吻、格式甚至对同一概念的解释都可能不一致。
主 Agent 统一执行 Skills 时，最终回复由主 Agent 生成，口径统一性更容易控制。虽然不同 Skill 的内部规则仍由不同团队维护，但对用户呈现的“表达层”是统一的。
多子 Agent 架构在维护边界上有明显优势：每个团队独立维护自己的 Agent、提示词和工具，互不干扰。当业务规则频繁变化时，团队可以独立发布更新，不需要与主 Agent 团队频繁协调。
主 Agent + Skills 架构则要求主 Agent 团队与各业务团队在接口契约、提示词兼容性、执行顺序上保持更高的一致性。Skills 的维护虽然可以分散，但其“被主 Agent 正确调用”的前提是主 Agent 能理解何时、以何种顺序使用这些 Skills。这给主 Agent 的提示词设计和测试带来更高要求。
多子 Agent 架构的执行轨迹分散在多个 Agent 的调用记录中。排查一次失败请求，需要跨多个 Agent 日志、摘要和委派指令还原完整链路，定位问题成本较高。
主 Agent + Skills 架构的执行轨迹更集中。主 Agent 的调用记录中可以看到每一步调用了哪个 Skill、传入了什么参数、返回了什么结果，调试路径更短。但这并不意味着可观测性天然更好：如果主 Agent 执行逻辑变长，单次调用的复杂度上升，仍需要结构化日志和链路追踪来辅助定位。
| 对比维度 | 多子 Agent 协作 | 主 Agent + Skills 与工具 |
|---|---|---|
| 上下文管理 | 每个子 Agent 独立上下文，需委派说明与摘要传递 | 主 Agent 统一上下文，Skill 直接读取当前状态 |
| 信息完整性 | 摘要可能丢失细节，后续 Agent 盲区风险高 | 中间结果保留在主上下文，信息更完整 |
| 交接开销 | 多次生成委派指令与摘要，串行等待明显 | 省去 Agent 间交接，仅保留业务步骤本身 |
| 回答口径 | 多团队风格可能不统一 | 主 Agent 统一生成回复，口径更一致 |
| 维护独立性 | 团队可独立维护各自 Agent | Skills 可分散维护，但主 Agent 协同要求更高 |
| 调试路径 | 需跨多个 Agent 日志拼装链路 | 执行轨迹更集中，但主 Agent 内部复杂度上升 |
| 适用规模 | 适合业务域差异大、弱依赖、可并行执行的场景 | 适合强依赖、串行为主、需共享上下文的场景 |
| 典型风险 | 上下文丢失、延迟叠加、口径分裂 | 主 Agent 提示词复杂度高、Skill 契约治理要求高 |
选型时，建议从“执行链路共享度”和“延迟敏感度”两个维度先做判断。
执行链路共享度高，即多个步骤需要频繁使用前序结果、用户补充条件或同一份数据时，主 Agent + Skills 架构通常更适合。上下文不必多次打包传递，执行更紧凑。
执行链路共享度低，即各业务步骤彼此独立、不共享中间状态时，多子 Agent 架构仍可保留。此时拆分带来的维护独立性收益大于交接成本。
延迟敏感度高的场景，优先减少不必要的架构性交接。即使业务本身必须串行，也应将串行放在同一主 Agent 的执行链中，而不是跨 Agent 传递。
团队协作边界强的场景，则要平衡技术收益与组织现实。如果业务团队无法接受共享主 Agent 上下文，可以保留子 Agent，但应通过统一回复模板、共享关键字段格式、限制摘要长度等方式降低上下文丢失和口径分裂的风险。
最重要的是，不要用“业务是否该拆分”来直接决定“执行是否该拆分”。业务知识可以按团队维护，但执行路径应尽量按数据依赖关系组织。
从多子 Agent 架构迁移到主 Agent + Skills 架构，不是简单的“把 Agent 改成函数”，需要注意以下几点。
首先要从子 Agent 的提示词和调用记录中，区分哪些内容是“业务规则”，哪些是“执行逻辑”。业务规则放入 Skills，例如配送时效计算规则、退款条件判断、会员权益优先级等；执行逻辑留在主 Agent 的编排层。不要试图把所有子 Agent 的提示词都塞进主 Agent，否则主提示词会迅速膨胀。
子 Agent 原来的工具调用，需要重新归类为通用工具供主 Agent 调用。工具命名、参数结构、返回格式应有统一约定，方便主 Agent 稳定理解。建议提供工具描述时明确输入输出示例和失败返回格式，避免主 Agent 猜测。
主 Agent 的上下文需要一套稳定的字段约定。例如用户 ID、订单 ID、配送地址、会员等级、优惠券 ID 等跨业务字段，应统一命名和类型。不同 Skill 之间共享这些字段时，不必再通过自然语言传递。
示例结构：
context:user_id: "u_12345"order_id: "o_20241022_001"shipping_address: "已验证"member_level: "gold"coupon_ids: ["c_01", "c_02"]last_query_result: {available_delivery_dates: ["2024-10-25", "2024-10-26"]}
该示例仅为通用概念示意，具体字段需根据业务实际定义。
子 Agent 合并后，原来分散在各子 Agent 中的工具权限会集中到主 Agent 的执行链上。需要重新审查主 Agent 的权限边界，确认其在什么条件下可以调用敏感操作，如退款、取消订单、修改会员信息等。审计日志应记录每次 Skill 与工具调用的入参、结果和触发条件。
建议先选取一两个串行依赖明显的业务链路做试点，观察延迟、准确率和用户反馈变化。保留原多子 Agent 编排作为回退路径，待主 Agent + Skills 链路稳定后再逐步切换其他业务。不要一次性替换所有子 Agent。
迁移后，监控关注点应从“各子 Agent 成功响应率”转向“主 Agent 各 Skill 调用成功率”“端到端延迟分布”“中间结果复用率”“用户重复提问次数”等指标。尤其是用户重复提问次数，能直观反映上下文是否真正打通。
多子 Agent 架构并非天然低效，主 Agent + Skills 架构也并非万能。问题的本质在于：业务能力可以按团队拆分，但执行上下文不应被过度切碎。
当多个子 Agent 需要频繁共享前序结果、用户条件和同一份数据时，跨 Agent 交接带来的上下文丢失、摘要生成、串行等待会显著推高延迟，并降低回答一致性。此时，将部分子 Agent 合并为主 Agent 可调度的 Skills 与工具，是一种更紧凑的执行方式。
反过来，当业务域差异大、依赖关系弱、并行性高时，保留多子 Agent 仍有其组织与工程上的价值。选型的关键不在于“拆还是不拆”，而在于“拆在哪一层”：拆在执行层，需要付出上下文传递的代价；拆在能力层，则能在保留模块化的同时，减少不必要的交接。
团队应定期回看 Agent 调用记录，找出那些几乎总是前后出现、共享同一批上下文信息的子 Agent 组合。这些组合往往是合并的第一候选。通过不断检视执行链路的数据依赖关系，才能让 Agent 架构真正服务于业务效率，而不是成为业务负担。