别把组织架构图搬进智能体：从“子智能体回收进主循环”看银行资产保全智能体的架构选择

Anthropic 2026 年 10 月 22 日的文章给出一个反直觉的判断：在多个企业部署中，“一个主循环 + 按需加载的技能和工具”经常在质量上胜过“协调者 + 一堆专科子智能体”，而且单任务成本和延迟往往更低（来源1）。

它点名的病根是康威定律：企业常给每个团队、每类问题配一个子智能体，最后智能体架构变成了组织架构图的复制品（来源1）。

LangChain 2026 年 1 月的文章把多智能体归为子智能体、技能、交接、路由四种模式，并主张先用单智能体，先加工具再加智能体，碰到明确瓶颈才升级（来源2）。

两篇文章并不矛盾：子智能体仍适合三类情况——单循环出现可测的上下文膨胀、需要用一次性干净上下文并行处理多个任务、工具选择或指令出现冲突（来源1）。

对银行资产保全的启示是：按“案件”而不是按“部门”组织智能体。一个案件一个主循环，法务、风险、评估、清收各条线的经验写成技能，系统操作写成工具；只把财产线索并行排查、独立复核和直接面对债务人的对话拆出去（本文分析）。

素材说明：本文依据 Anthropic 官网文章（来源1）与 LangChain 官方博客（来源2）。两者均出自智能体平台厂商，文中的性能对比为厂商自述或示意性测算，未见独立复现；LangChain 文章发布于 2026 年 1 月，早于 Anthropic 文章约九个月。凡来源事实标注编号；资产保全场景的映射、设计与建议均标注“本文分析”。本站此前关于资产保全智能体的模型选型、微调与 Harness、可验证训练环境的讨论，可与本文对照阅读。

一、两篇文章到底说了什么

1.1 Anthropic：为什么要把子智能体“折回”主循环

文章总结了大型组织构建智能体时的五种典型失败（来源1）：

替代方案是渐进式披露：智能体只看到技能和工具的简短描述，用到时才完整加载（来源1）。理由有三：

1. 共享上下文答案更好：看过每一步结果的智能体能把它们串起来，胜过一组子智能体交回的摘要，也减少有损交接。
2. 渐进式披露避免上下文膨胀：这消除了过去拆分子智能体的主要理由。Anthropic 称针对更强模型，Claude Code 的系统提示词缩减了 80% 以上。
3. 模型更强了：更多决策可以从框架代码移到模型本身；僵硬的多智能体结构反而常常阻碍新模型多做事。

文章建议的目标形态（来源1）：

• 一个模型、一个上下文窗口，运行开放式工具循环；轮次与成本预算、写操作闸门由框架设定。
• 模型每轮发出一批工具调用，框架并行执行后把原始结果交回同一模型，由它决定下一步。
• 模型第一轮在上下文中写出计划，随结果修订——写计划的和执行计划的是同一个模型。
• 顺序和领域流程放进技能；硬性限制（校验、审批闸门）和对话中途才需要的东西（如记忆查询）放进工具；参考资料放进知识库。
• 工具按用户意图分组而非一个接口一个工具，超过 30 至 50 个工具定义后工具选择质量会下降；每个工具自行检查调用者权限并返回模型能读懂的拒绝信息，一个循环即可服务权限不同的用户。

迁移方法同样具体（来源1）：先建端到端评测（10 个黄金样例就够起步）；从使用最多、上下文耦合最紧的子智能体开始合并；先把子智能体当工具调用，再逐个改写成技能加工具；比较时看哪些任务“翻转”了，而不仅看总分。Anthropic 举例：一次合并降低了延迟，却让主智能体自己查订单后直接作答、不再询问物流专员，导致一条原本通过的流程失败，而且这个问题两次运行中只出现一次。所以每个任务要跑不止一次。

1.2 LangChain：四种模式与它们的代价

（来源2）

它给出的示意性测算（来源2）：

• 单次请求：子智能体模式 4 次模型调用，其余三种各 3 次。
• 重复请求（两轮）：子智能体共 8 次，技能和交接各 5 次，路由 6 次。
• 多领域比较查询（每个领域约 2000 token 资料）：子智能体约 5 次调用、约 9K token；技能约 3 次调用、约 15K token；交接 7 次以上、约 14K token 以上；路由约 5 次调用、约 9K token。

结论是：单次和重复请求，技能和交接更省；需要并行、领域资料很大时，子智能体和路由更省（来源2）。

二、资产保全为什么特别容易掉进“组织架构图陷阱”（本文分析）

本节为本文分析。

资产保全天然跨部门：一笔不良贷款从风险预警、贷后检查、资产保全部接手，到法律合规审查、委托律师起诉、申请财产保全、强制执行、抵押物评估拍卖、债权转让或核销，至少经过五六个条线。按直觉，很容易设计成：

协调者 → 尽调子智能体 / 法务子智能体 / 评估子智能体 / 清收子智能体 / 核销子智能体

这正是来源1 描述的失败模式在银行的翻版，而且后果更重：

1. “传话游戏”会丢掉决定案件走向的细节。尽调子智能体交回一段摘要，法务子智能体据此起草诉状。可资产保全里最致命的往往是摘要最容易省略的东西：最后一次催收函的送达证据是否构成诉讼时效中断、抵押登记的顺位、保证合同的保证期间、借款人名下财产的查封轮候情况。
2. “缝合怪”提示词在银行会变成制度冲突。法务条线要求“先保全后起诉”，处置条线强调“优先协商以降低处置成本”，核销条线强调“穷尽追索手段”。把三套规则都塞进一个系统提示词，或分散在三个子智能体里各自执行，都会产生不一致的结论，而且难以追溯是谁的规则起了作用。
3. 局部评测会掩盖整体失败。法务子智能体的诉状起草得分很高，评估子智能体的估值误差也很小，但案件整体可能因为没赶在财产被转移前申请保全而失败。真正该衡量的是“案件回收结果和合规性”这一端到端指标。
4. 子智能体蔓延会变成模型风险管理难题。每个子智能体都是需要登记、验证、监控的模型应用；分行、总行各建一套，很快就没人说得清全行有多少个保全相关智能体、各自用什么提示词。

三、以“案件”为中心的单一主循环（本文分析）

本节为本文分析。

3.1 总体结构

把来源1 的目标形态映射到资产保全：

3.2 把规则放在正确的位置

来源1 的一条关键建议是：硬性前置条件放进工具，而不是写进提示词。在资产保全里可以这样落地：

• “提交财产保全申请”工具自行检查：是否已核验债权金额、是否已有担保方式、是否已获法务审批；缺一项就返回明确指令，例如“请先调用债权金额核验工具”。
• “核销申报”工具检查核销条件与审批层级，不满足时返回原因，而不是靠模型“记得”制度。
• 每个工具按调用者身份过滤：分行客户经理看不到其他分行案件；外包律师只能看到委托范围内的材料。这正对应来源1 所说“一个循环服务不同权限的用户，而不必为每个权限级别单建智能体”。

工具数量要控制在来源1 提示的 30 至 50 个以内，并按意图分组。例如不要把 12 个外部查询接口各做一个工具，而是做一个“查询财产线索”工具，用参数选择来源。

3.3 为什么单循环更适合资产保全的推理方式

资产保全的核心判断大多是跨环节的综合判断：是否值得起诉，取决于财产线索、担保有效性、诉讼成本和时效；选择协商、诉讼还是转让，取决于全部前序事实。来源1 所说的“看过每一步结果的智能体能把它们串起来”，在这里就是“同一个上下文里同时看到时效证据、财产线索和担保瑕疵”。

四、哪些环节仍应拆出去（本文分析）

本节为本文分析。

依据来源1 的三条保留标准和来源2 的模式特征，资产保全中有三类环节值得保留子智能体或交接：

一个判断口诀：能按“数据彼此独立”切开的，可以拆；只能按“部门职责”切开的，不要拆。

五、评测：先有端到端评测，再谈架构（本文分析，结合来源1）

来源1 反复强调：比较架构的依据是任务完成评测，而且要有一套由中心团队维护的端到端评测，再加各技能负责团队自带的小评测（来源1）。落到资产保全：

1. 黄金案件集：从已结案案件中挑选 10 至 30 个，覆盖抵押、保证、信用、破产、跨地域执行等类型，标注正确的处置路径和关键事实。（本文分析）
2. “不可违反规则”逐条成题：诉讼时效、催收行为规范、个人信息使用范围、审批层级，每条至少一个测试任务。来源1 要求为生产中每条一起运行的链路、每条不能违反的规则都准备任务。
3. 每个任务多次运行：来源1 的例子里，问题两次中只出现一次。资产保全的结论关乎真金白银，至少应多次运行观察稳定性。
4. 看“翻转”而不只看总分：合并一个子智能体后，逐个检查哪些案件从通过变成失败。
5. 事件时间戳与回放：来源1 提到给重要事件打时间戳以便回放。资产保全案件周期长达数月甚至数年，按“立案、保全、开庭、判决、执行、拍卖”节点记录，可以把真实案件切成可回放的评测片段。（本文分析）

六、组织：中心团队管主循环，条线团队管技能（本文分析，结合来源1）

来源1 建议由一个小型中心团队负责系统提示词和端到端质量，审核每个新工具和评测；各团队的职责从“拥有一个智能体”转为“拥有技能和工具”，每个技能有明确负责人（DRI），自带评测，并定期清理无用技能（来源1）。

在银行可对应为：

这样做的直接收益是：监管或内审问“这个结论依据了什么规则”，可以定位到具体技能及其版本和负责人。

七、一个重要提醒：本地模型的能力门槛不同（本文分析）

本节为本文分析。

来源1 的核心前提之一是“模型更强了”，它提到的是 Anthropic 当前的前沿模型。很多银行出于数据安全会在行内部署中小规模开源模型。模型越弱，单一主循环能稳定管理的工具数、技能数和上下文长度就越有限，原本“多余”的框架结构可能仍然必要。

因此不要直接照搬“全部折回主循环”的结论，而应遵循来源1 真正的方法论：测量、一次只改一处、保留经得起检验的做法。对行内模型，可以先把案件主循环限定在尽调和处置建议这类只读、可复核的环节，写操作全部走工具闸门和人工审批；随着模型升级，再逐步把子智能体折回。

八、分阶段迁移路线（本文分析）

九、结语

本文分析：资产保全智能化最容易犯的错，不是模型不够强，而是把部门边界当成智能体边界。两篇文章给出的共同答案是：先用一个看得到全局的主循环，把条线经验写成可审计的技能，把制度红线写进工具；只有在数据可以独立切分、需要独立复核或必须直接对外对话时，才引入多个智能体。对银行而言，这样做还有一个额外好处——规则、权限和责任都落在可登记、可审计的位置上。

事实来源

1. Anthropic《Building agents: When to fold subagents into your main agent loop》（来源1，2026-10-22）：五种失败模式、约 2 倍运行速度对比、Claude Code 系统提示词缩减逾 80%、保留子智能体的三条标准、单一主循环目标形态、30 至 50 个工具阈值、工具内权限检查、10 个黄金样例起步、“两次运行只出现一次”的翻转案例、中心团队与技能 DRI 治理。
2. LangChain《Choosing the Right Multi-Agent Architecture》（来源2，2026-01-14）：四种模式定义与取舍、三种场景的模型调用次数与 token 测算、“先单智能体、先加工具”的建议。
3. Anthropic 多智能体研究系统（来源3）：两篇来源均引用的多智能体正面案例；来源2 引述其多智能体架构在内部研究评测上比单智能体高 90.2%。
4. single-agent-loop-kit（来源4）：Anthropic 提供的迁移工具包，来源1 引用。

本文推论部分（非来源表述）：第二、三、四、七、八节全部内容，第五、六节中的银行映射，各处“本文分析”段落与结语。

本文不构成投资建议、技术选型建议或法律意见。

（内容由AI生成，仅供参考）