AI Agent 架构正在变复杂:一套框架看懂各家方案进展

发布时间:2026/7/17 0:32:30
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 工程的关键能力。模型会继续变强工具会继续增加平台会继续完善。真正拉开差距的是谁能把这些能力组织成一套可控、可恢复、可复盘的工作系统。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】