夜雨聆风AI Agent 架构正在变复杂：一套框架看懂各家方案进展
从 LangChain、Claude Code、OpenAI、Google 到 Manus，看 agent 如何长出一套真正可运营的工作系统。
过去一段时间，各家公司都在密集更新 agent 相关能力。
LangChain 在讲 Deep Agents、Dynamic Subagents、Wiki Memory 和更小的 interpreter runtime。Claude Code 在讲 subagents、工具权限、默认模型和后台任务。OpenAI Agents SDK 提供 handoff。Google ADK 和 Gemini API 把 workflows、background execution、webhooks、managed agents、secure sandbox 摆上了公开文档。CrewAI 和 AutoGen 继续沿着多角色协作团队演进。Manus 则把 hosting modes、scheduled tasks、wide research、connectors 做成了产品体验。
这些方案放在一起看，表面是很多不同的产品名和框架名，底层回答的是同一个问题：
当 agent 从单个执行者变成可委托、可并行、可长期运行的工作系统时，系统如何保证任务被正确拆解、受控执行、可靠汇总、可恢复、可审计。
这就是我最近越来越关注的 委托控制层。
它决定一个 agent 系统能否从“能演示”走向“能持续工作”。
一、为什么 agent 会走向委托控制层
单个 agent 很适合处理短任务。让它解释一段代码、改一个小 bug、总结一篇文章、查一个接口，都可以跑得很顺。
问题出现在长任务里。
一个真正有价值的 agent 任务，往往会变得很长：读多个文件，查多个来源，跑测试，修改代码，等待用户确认，回头修正方案，再把结果整理成可交付文档。
这时系统会遇到五个天然约束。
第一，上下文会变重。长任务会产生搜索结果、命令输出、文件 diff、错误日志、审批记录和中间判断。主线程长期背着这些内容，判断质量会下降。
第二，覆盖面会变窄。一个 agent 顺序推进，很容易被某条路径吸住，遗漏其他分支。复杂研究、代码库分析、方案比较，都需要多个执行单元同时探索。
第三，能力会带来风险。agent 一旦能读文件、写文件、联网、执行命令、调用 MCP、操作浏览器，系统就必须明确它能碰什么能力，哪些动作需要审批，哪些日志需要脱敏。
第四，结果需要验收。子任务跑完，只代表局部动作完成。整体结果还需要合并、去重、冲突裁决、证据检查和最终验收。
第五，运行会被打断。长任务会等人、等外部系统、等审批，也会遇到模型切换、成本上限、环境重启和上下文压缩。成熟系统需要 checkpoint、pause/resume、event stream、webhook 和 trace。
所以，agent 工程的核心问题正在变成：
如何把一个开放式目标，转化成一组受控的、可观察的、可验收的执行单元。
这句话听起来像架构原则，落到真实产品里，就是各家公司最近都在推进的 subagent、handoff、workflow、managed agent、sandbox、memory 和 eval。
二、AI Agent 7 层框架
我把这个问题拆成七层。以后看任何 agent 平台，都可以沿着这七层判断它解决了什么，留下了什么。
第一层，目标定义层。系统先要知道任务的交付物是什么，成功标准是什么，风险等级是什么。很多 agent 失败，起点就很模糊：任务描述像愿望，缺少验收标准。
第二层，任务拆解层。复杂目标要拆成子任务。可以按角色拆，比如 reviewer、debugger、researcher；可以按流程拆，比如调研、实现、测试、总结；可以按文件或模块拆；也可以按探索分支拆。
第三层，委托路由层。拆出来的任务要交给合适的执行单元。这里会出现 triage agent、static subagent、dynamic worker、workflow node、remote agent session 等不同形态。
第四层，执行边界层。每个 worker 能使用哪些工具、读写哪些文件、调用哪些 MCP、能否联网、能否执行命令、凭据如何注入，都要在这一层明确。
第五层，状态与恢复层。长任务需要保存状态。中间产物、运行事件、审批等待点、失败原因、恢复位置，都要能被系统重新读回来。
第六层，汇总与验收层。多个 worker 的结果需要合并。系统要判断哪些结果可信，哪些结果冲突，哪些结果需要测试或人工复查。
第七层，治理反馈层。一次运行结束后，要留下成本、耗时、失败点、审批记录、trace、可复用 workflow、可复用 subagent 和 memory。系统通过这些资产越跑越稳。
这七层合起来，就是委托控制层：
Delegation Control =Goal Contract+ Task Decomposition+ Agent/Tool Routing+ Capability Boundary+ Durable State+ Result Verification+ Governance Feedback
更接地气地说：先定义交付物，再拆任务；先限制能力，再并行执行；先保留状态，再扩大自治；先设计验收，再追求规模。
三、各家公司方案放进这个框架怎么看
LangChain：把委托推进到程序化编排
LangChain 这条线最近很有代表性。
Deep Agents 把规划、文件系统、subagent spawning、长期记忆、人类介入和 durable execution 放在一套 harness 里。Dynamic Subagents 进一步让模型写 orchestration 代码，用程序结构表达 fan-out、branching、loop 和并行。WASM + QuickJS 的小运行时方案，则回答这段 orchestration 代码跑在哪里、如何隔离、如何暂停恢复。
这条路线的价值在于灵活。
当任务路径高度开放，比如大规模研究、代码库横向扫描、多资料源调查、测试矩阵生成，固定流程很难覆盖所有分支。让模型写一小段调度代码，再由 harness 限制它能调用哪些 subagent 和工具，是一种很有想象力的结构。
它也带来更高的工程要求。模型写 orchestration 代码越强，runtime、capability bridge、成本控制、结果验收就越重要。LangChain 这条线的关键词可以概括为：程序化委托、受控执行、trace 驱动治理。
Claude Code：把 subagent 做成稳定专家
Claude Code 的 subagent 更像开发团队里的固定专家。
你可以定义 reviewer、debugger、researcher、security reviewer，每个专家有自己的 prompt、上下文窗口、工具权限、模型选择和 memory。它的强项是上下文隔离和权限隔离。
这非常适合开发者工具场景。
代码审查、调试、测试、文档、迁移、安全检查，本来就容易形成稳定角色。每个角色独立配置工具和上下文，主线程负责调度和汇总，整体结构会更稳。
Claude Code 这条线的关键词是：专家复用、上下文隔离、权限分层。
OpenAI Agents SDK：把 handoff 做成业务路由
OpenAI Agents SDK 的 handoff 很像业务系统里的转接。
一个 triage agent 判断用户需求，然后交给 billing、refund、FAQ、research、code 等 specialist。它最强的层级是路由层。
这个抽象适合客服、helpdesk、企业内部问答、销售/法务/财务分流。业务边界清楚，专家职责稳定，交接上下文清楚，handoff 的价值就很直接。
对更复杂的开放式任务，handoff 通常还需要和 graph workflow、sandbox、review gate、durable state 组合。它解决的是“交给谁”，后面还要继续解决“如何长期执行、如何验收、如何恢复”。
OpenAI 这条线的关键词是：业务分流、专家转接、平台集成。
Google ADK / Gemini：把 agent 当成平台资源管理
Google 的路线更偏工程平台。
ADK 支持 graph workflow、dynamic workflow、collaborative workflow、template workflow。Gemini API 文档里已经能看到 background execution、webhooks、managed agents、remote MCP、AGENTS.md、SKILL.md、secure Linux sandbox 等运行接口。
这条线最值得关注的是 runtime contract。
一个 long-running agent 需要有 interaction id，需要状态机，需要 event stream，需要 webhook，需要从 last_event_id 恢复，需要 managed environment，需要文件挂载和 sandbox。这些能力让 agent 更像平台里的长期任务资源。
Google 这条线的关键词是：异步运行、托管环境、平台合同。
CrewAI：用角色团队组织任务
CrewAI 的抽象更接近人类团队。
你定义 researcher、writer、reviewer、manager，然后通过 process 和 task dependency 组织协作。它的好处是直观，适合研究、写作、运营、咨询分析这类任务。
这条路线的价值在于启动成本低，团队角色容易理解。复杂任务里要特别关注重复委托、过度沟通和成本曲线。
CrewAI 的关键词是：角色协作、任务依赖、团队隐喻。
AutoGen：研究多 agent 协议和团队行为
AutoGen 更像一个 agent communication framework。
它强调 team preset、对话协议、终止条件、状态观察和团队协同。适合研究多 agent 策略、协作行为、selector、round robin、group chat 这类机制。
生产级长任务还需要补上更硬的 workflow、artifact state、sandbox、verifier 和 governance。
AutoGen 的关键词是：团队协议、协作策略、状态观察。
Manus：把长任务生命周期产品化
Manus 的公开材料更偏产品化工作台。
hosting modes、scheduled tasks、wide research、connectors、browser/computer 操作、团队入口，这些都指向一个方向：把 agent 的长期任务生命周期变成用户能看见、能恢复、能协作、能交付的产品体验。
它给我们的启发很实际：委托控制层最终要被产品化。用户看到的应该是任务状态、运行模式、连接器权限、计划任务、团队协作和检查点。
Manus 的关键词是：任务生命周期、产品体验、长期工作台。
四、真正要追踪的问题
未来看 agent 平台，我会持续追踪七类问题。
第一，任务拆得怎么样。子任务是否独立，是否可并行，是否可验收，是否覆盖关键分支。拆解质量决定多 agent 系统的上限。
第二，上下文怎么交给 worker。worker 拿到完整上下文、摘要、文件、artifact，还是专门构造的 task contract。上下文包装会直接影响执行质量。
第三，能力边界有多清楚。worker 能读什么、写什么、联网到哪里、调用哪些 MCP、凭据如何注入、哪些动作要审批。能力边界就是 agent autonomy 的真实边界。
第四，状态能不能连续。是否支持 checkpoint、pause/resume、event stream、webhook、resume point。长任务 agent 的成熟度，很大程度看它如何处理中断。
第五，结果怎么验收。是否有 evidence、verifier、test、rubric、human review gate。委托之后必须有验收，系统才有闭环。
第六，成本曲线怎么控制。fan-out 数量、模型档位、token 增量、wall-clock、失败重试都要进入预算控制。多 worker 系统的成本常常会非线性增长。
第七，运行结束后留下什么。一次成功的运行，最好能沉淀成 workflow、subagent、skill、memory、policy 或 review rubric。系统能从运行中学习，才会越跑越稳。
五、选型时怎么判断
任务流程清楚、稳定性要求高，优先用 graph workflow。审批流、数据处理流、固定业务流程、合规场景都适合这条路。
专家角色稳定、复用频率高，优先用 static subagents。代码审查、调试、安全检查、测试生成、文档整理都属于这一类。
业务分流清楚，优先用 handoff。客服、helpdesk、企业内部问答、销售/法务/财务分流，都可以用 triage agent 加 specialist。
路径高度开放，需要大规模探索，考虑 dynamic subagents。大规模 research、多资料源调查、代码库横向扫描、多方案比较，都适合程序化编排。
任务需要完整系统能力，使用 full sandbox、cloud computer 或 worktree isolation。依赖安装、浏览器操作、系统级调试、多文件构建都属于这类。
任务很小，保持单 agent 加结构化工具。简单任务保持简单，系统反而更稳。
六、对我们自己的工作流有什么启发
第一，复杂任务开始前，先写一个 task contract。
目标：交付物：成功标准：允许使用的工具：禁止触碰的范围：是否可并行：是否需要人工审批：验收方式：预算上限：trace / artifact 保存要求：
这个模板会把自治能力压进清楚的工程边界里。
第二，把 subagent 分成两类。
一类是固定专家，比如 reviewer、debugger、researcher、evaluator、documentation writer、security checker。它们负责稳定复用。
另一类是动态 worker。它们针对当前任务临时生成，有明确输入输出，运行在受控 runtime，完成后可以销毁，也可以沉淀成新专家。
第三，把运行时分成三档。
小任务用 single-agent。需要 fan-out、branching、loop、subagent coordination 的任务，用 interpreter-grade orchestration，只暴露少量 bridge functions。需要真实系统能力的任务，用 full sandbox、worktree 或 computer use。
第四，把验收方式前置。
测试通过、diff review、引用来源可追溯、rubric 打分、verifier 复查、human approval、trace outcome label，这些验收方式会反过来决定任务怎么拆、worker 怎么输出。
七、最后的判断
agent 系统正在从“模型调用工具”升级为“可委托、可恢复、可验收、可治理的工作系统”。
LangChain、Claude Code、OpenAI、Google、CrewAI、AutoGen、Manus 给出的方案各有取舍。真正值得长期追踪的是委托控制层：
任务如何拆，派给谁，给多少能力，如何保存状态，如何验收结果，如何把一次运行沉淀成可复用资产。
这也是下一阶段 agent 工程的关键能力。模型会继续变强，工具会继续增加，平台会继续完善。真正拉开差距的，是谁能把这些能力组织成一套可控、可恢复、可复盘的工作系统。
参考来源
LangChain Deep Agents overview Introducing Dynamic Subagents in Deep Agents Running Untrusted Agent Code Without a Sandbox Wiki Memory Claude Code Subagents docs OpenAI Agents SDK Handoffs Google ADK Workflows Gemini API Background execution Gemini API Webhooks Building Managed Agents Antigravity Agent CrewAI Collaboration AutoGen Teams Manus Blog