Agent 框架决定 Agent 如何从用户目标走到最终结果。它负责组织推理、工具调用、记忆读取、状态更新、错误恢复和最终输出。选框架不是选最流行的库，而是选择一种适合任务复杂度、可靠性要求和团队能力的控制方式。
从工程角度看，多数 Agent 执行框架都可以拆成三部分：上下文组织、状态机控制和工具执行。差异在于它把多少决策权交给模型，多少控制权留给代码。
Agent 框架要解决什么问题
一个 Agent 在执行任务时会不断面对以下问题：
- 当前目标是什么
- 已经知道哪些信息
- 下一步应该调用哪个工具或生成什么内容
- 工具失败后如何处理
- 什么时候应该停止
- 如何把中间结果合成为最终交付物
框架把这些问题组织成可运行流程。没有框架，Agent 很容易变成一次性 Prompt 拼接，框架过重，又会限制灵活性并增加工程成本。
三种常见架构模式
框架不是越全越好。团队应先明确任务类型、失败成本、评估方式和上线边界，再决定是否需要复杂框架，框架可以进一步归纳为三种工程范式：最小可用范式、工作流式和动态规划式。
1. 最小可用（Pi）
编码 Agent、沙箱、浏览器、文件操作，OpenHands 最小可用范式只保留必要的 Prompt、上下文和少量工具调用。它适合轻交互、低风险、单轮或短流程任务。
| 优点 | 缺点 |
|---|---|
| 成本低、延迟低、实现快 | 缺少多步规划和复杂状态管理 |
适合：FAQ、简单信息抽取、单次内容生成、轻量分类。
2. 工作流式（LangGraph）
自研工作流、强业务流程和强合规、维护成本和模型能力接入、LangGraph支持状态机、图式编排、可恢复执行 状态建模和节点边界设计
工作流式由开发者预先定义流程，模型只在关键节点负责理解、生成或判断。它适合流程稳定、合规要求高、结果需要可控的业务。
常见模式包括链式、路由、并行、评审和状态机。
| 优点 | 缺点 |
|---|---|
| 稳定、可审计、易测试 | 对开放任务适应性不足 |
适合：审批、客服工单、数据处理、标准报告、企业流程自动化。
3. 动态规划式（类Manus）
Claude Agent SDK，Deep Agents，快速构建工具型 Agent（长任务、Sub Agent、文件系统协作），子任务拆分和结果整合，沙箱、浏览器、文件操作，安全边界和执行 Trace
动态规划式让模型在运行时自主拆解任务、选择工具、根据反馈调整路径。它适合开放、探索、路径不明确的任务。
| 优点 | 缺点 |
|---|---|
| 灵活，能处理未知情况 | 成本、延迟和结果方差更高 |
适合：深度研究、复杂排错、代码任务、网页操作、多源信息整合。
框架选型指南
选择框架时，可以按任务特征判断。
| 任务特征 | 推荐范式 |
|---|---|
| 单轮、低风险、低成本优先 | 最小可用范式 |
| 流程明确、合规要求高 | 工作流式 |
| 路径不明确、需要探索 | 动态规划式 |
| 长任务、多步骤、需审计 | Plan-and-Execute + Trace |
| 依赖实时反馈 | ReAct |
| 需要经验沉淀 | Reflexion + Memory |
| 多人或多角色协作 | 主从 Agent 或 Multi-Agent |
进一步决策可以看三项约束：
- 可控性优先时，选择工作流或混合架构。
- 灵活性优先时，选择动态规划式，但必须加预算和护栏。
- 成本优先时，先做最小可用范式，不要提前引入复杂编排。
工程挑战
框架上线后，常见挑战包括：
| 挑战点 | 现象描述 | 应对方法 |
|---|---|---|
| 循环失控 | Agent 重复调用工具、反复尝试同一失败操作，或生成偏离原始目标的子任务 | 设置最大步数、整体超时、目标锚定和重复操作检测 |
| 成本不可预测 | 工具调用和模型调用次数过多 | 设置 token 预算、模型分层、并行上限和提前停止条件 |
| 状态漂移 | 长任务中目标、约束和用户偏好被遗忘 | 使用状态表、Todo list、上下文压缩和关键约束重注入 |
| 工具混淆 | 工具过多导致选择错误、参数错误或幻觉调用 | 使用工具分层、按需加载和权限隔离 |
| 错误恢复不足 | 一次工具失败导致整条任务中断 | 对错误分类处理，区分重试、降级、人工介入和终止 |
| 可观测性不足 | 多次模型调用、工具交互和状态转换后，失败原因难以追溯 | 建立全链路 Trace，记录模型 I/O、工具调用参数、结果、耗时和关键状态变更 |
| 决策依据不可追踪 | 无法判断 Agent 为什么选择某个工具、放弃某条路径或得出某个结论 | 记录关键决策日志，保留约束、证据、备选方案和风险判断 |
常见失败模式
| 失败模式 | 表现 | 处理方法 |
|---|---|---|
| 分工过细 | 协调成本超过执行收益 | 合并子任务，减少 Agent 数量 |
| Main Agent 失控 | 任务分派不清，结果无法整合 | 使用结构化子任务和返回格式 |
| 上下文丢失 | Sub Agent 忽略关键约束 | 在输入中显式列出硬约束和完成标准 |
| 结果冲突 | 多个 Agent 给出矛盾结论 | 引入证据排序和冲突解决规则 |
| 成本膨胀 | 并行调用过多模型和工具 | 设置预算、超时和最大 Agent 数 |
| 权限混乱 | Sub Agent 执行越权动作 | 按角色隔离工具权限 |
选型建议
框架选型可以遵循以下顺序：
- 先用最小可用范式验证任务价值和基础质量。
- 如果流程稳定，把关键路径固化为工作流。
- 如果任务路径不确定，在局部引入 ReAct 或动态规划。
- 如果任务周期长，引入 Plan-and-Execute、状态持久化和上下文压缩。
- 如果需要持续优化，引入 Reflexion 和经验记忆。
- 如果需要并行或专业分工，再引入 Multi-Agent。
- 无论选择哪种框架，都必须建设 Trace、评估集和安全护栏。
引入 Multi-Agent 前，还需要额外回答几个问题：
- 任务是否真的可以拆分，而不是人为拆分。
- 拆分后是否能并行，或是否能带来专业质量提升。
- 子任务的输入、输出和完成标准是否清晰。
- Main Agent 是否有足够能力整合冲突结果。
- 工具权限、Trace 和评估体系是否已经准备好。
- Multi-Agent 带来的收益是否超过成本和延迟增加。
落地顺序可以是：
- 先用单 Agent 建立可用基线。
- 找出单 Agent 的瓶颈：上下文、工具、并行、复核还是专业性。
- 只为瓶颈引入一个 Sub Agent 或 Reviewer。
- 固化子任务输入输出格式。
- 用评估数据验证质量、成本和耗时是否改善。
- 再逐步扩展更多 Agent。
框架的目标不是展示 Agent 有多自主，而是让系统在真实约束下稳定完成任务。
Agent 技术形态
工作流与 Agent 并存
很多生产系统不是纯工作流，也不是纯自主 Agent，而是混合架构。
工作流外壳：控制入口、权限、步骤、审计和交付格式
智能内核：在关键节点完成理解、检索、生成、决策和修正
工具网关：统一执行外部操作
评估系统：持续监控质量和成本混合架构的优势是把确定性流程交给代码，把不确定判断交给模型。这样既能保留 Agent 的灵活性，又能满足生产系统对稳定性和审计的要求。
Agent 技术形态正在收敛
在 2025 年 10 月之前，Agent 的技术发展仍处于快速演进阶段。两个信号能说明这一点：Manus 从 3 月发布到 10 月经历了 5 次大规模架构重构；LangChain 直到 2025 年 10 月才正式发布 1.0，并同步推出 Deep Agents。
从 2025 年 10 月起，Agent 技术形态开始收敛。主流框架逐渐靠近 Claude Agent SDK 和 Deep Agents 所代表的执行范式：主 Agent 负责任务拆解和协调，Sub Agent 或任务节点负责局部执行，文件系统或外部存储承担上下文卸载和共享工作区，工具调用采用分层设计，并通过上下文压缩、Trace、评估和人工介入支撑长任务。
这些能力说明 Agent 工程的重点已经从单次 Prompt 转向上下文管理、状态控制和执行可靠性。
1. 主从 Agent 架构
主从架构采用层级化任务调度模式，Main Agent 负责任务拆解、子任务分派和结果整合，Sub Agent 专注执行具体子任务。
| 能力 | 作用 |
|---|---|
| 上下文隔离 | 子任务执行过程不会污染 Main Agent 的上下文 |
| 并行执行 | 多个子任务可以同时进行，降低总耗时 |
| 专业化分工 | 不同 Sub Agent 可以配置专属工具、权限和 System Prompt |
| token 效率 | Sub Agent 完成任务后只返回结论、证据、风险和需要决策的问题 |
主从架构不是为了增加 Agent 数量，而是为了在复杂任务中建立清晰的责任边界、更低的上下文污染和更可靠的结果复核。
2. 自主规划能力
规划能力让 Agent 能够把复杂任务拆解为可执行步骤，并根据工具反馈动态调整执行策略。Plan-and-Execute、ReAct、动态规划和 Todo list 都可以看作不同粒度的规划机制。
即使是一个不执行外部动作的 Todo list 工具，也能作为上下文工程手段，帮助 Agent 保持目标、步骤和完成状态。规划能力是长时间跨度任务能够持续推进的关键。
3. 文件系统作为外部工作区
很多长任务需要把中间结果保存到文件，而不是全部留在上下文中。文件系统可以承担四类职责：
- 上下文卸载：保存长文档、日志、数据和中间结果，防止上下文窗口溢出
- 共享工作区：Main Agent 与 Sub Agent 之间交换成果
- 长期记忆：保存项目笔记、偏好、失败经验和业务规则
- 技能载体：保存可复用脚本、模板和流程说明
文件系统能力越强，越需要权限边界、目录隔离和变更审计。
4. 上下文自动压缩
长任务会持续消耗上下文窗口。当 token 使用量接近上限，例如达到 200k 上下文的 80% 时，成熟框架通常会触发总结模型，对前文进行摘要压缩，释放上下文空间。
压缩不是简单截断历史，而是保留目标、硬约束、关键决策、未完成任务、工具结果和风险点。否则压缩会造成状态漂移。
分层工具体系
成熟框架通常不会把所有工具直接放入模型上下文，而是分层提供。
| 层级 | 内容 | 设计目标 |
|---|---|---|
| 原子工具层 | 文件读写、Shell、浏览器、搜索、任务分派 | 保持基础能力稳定 |
| 沙箱工具层 | 通过命令行使用系统已有程序 | 减少工具定义数量 |
| 代码与包层 | 脚本、库、领域函数 | 复用复杂逻辑 |
| 业务接口层 | CRM、订单、审批、数据库、内部 API | 连接真实业务系统 |
分层工具体系的本质是渐进式披露。模型只在需要时获得具体能力，降低上下文混淆和误调用风险。
第 1 层：原子工具层
原子工具层通常只保留 20 个左右核心、高频、正交的工具，例如 read_file、edit_file、browser_navigate、bash、ls、task。这层工具的目标不是覆盖所有业务能力，而是确保模型最基础的交互能力稳定可靠。
第 2 层：沙箱工具层
沙箱工具层的核心是去工具化。不再为每个程序封装独立 Function Calling 定义，而是让 LLM 通过 bash 调用沙箱中预装的程序。
以视频处理为例，传统方式可能会预定义 convert_video、resize_video、extract_audio 等大量专用工具及繁杂参数，工具列表会快速膨胀。沙箱方式只提供 bash，并允许模型探测环境，在发现 ffmpeg 后直接执行命令完成任务。
这种方式把工具定义排除在上下文之外，节省 token，也降低工具列表过长导致的混淆。
第 3 层：代码与包层
代码与包层适合复杂串行逻辑。与其让 Agent 进行多次 LLM 往返交互，不如提供 Python 库、业务 SDK 或领域函数，让 Agent 编写脚本一次性执行所有步骤。
例如查询多个国家的手机价格并换算成美元，传统工具调用可能需要上百次请求；代码方式只需要读取数据、循环汇率换算、排序输出。它把重复动作交给程序，把判断和编排留给 Agent。
垂直业务如何适配通用 Agent 架构
将现有 Workflow 升级为 Agent
当通用型 Agent 架构逐渐成熟，真正的难点会转向业务适配。企业不应该把所有业务知识一次性放入上下文，而应把知识、接口和行为边界做成可治理的工程资产。
很多企业已有稳定 Workflow，不需要全部重建。更现实的路径是借鉴 Claude Deep Research 的 Prompt 架构，把复杂业务流程和决策逻辑沉淀到 Main Agent 的认知体系中。
一个可落地的升级结构通常包含三个核心 Prompt：
- Main Agent：负责任务拆解、子任务分派、风险判断和结果整合。
- Sub Agent：专注执行具体子任务，并返回结论、证据、不确定项和失败路径。
- 后处理 Agent：负责引用校验、格式清理、结构化输出或合规审查。
如果使用 Claude 4.5、Gemini 3、GPT-5.2 等能力足够强的模型，可以尝试完整的主从 Agent 方案。如果模型能力次一级，应降低任务复杂度，从相对稳定的业务场景开始。
Agent 模式相较传统 SFT 的优势是迭代更快。SFT 往往需要数据清洗、人工标注和反复训练，周期可能以周计算；Agent 路径通过消耗更多 token 换取更快实验，把很多迭代压缩到按天计算。
业务知识 Skill 化
将业务文档、SOP、案例库和操作规范抽象为 Skills，存储在 Agent 的文件系统中。模型根据任务需求按需加载，而不是一次性全部放入上下文。
这类 Skills 应包含适用场景、输入要求、操作步骤、禁止事项、示例和验证方式。它们本质上是可维护的业务能力包。
业务接口 MCP 化
将企业业务 API 封装为 MCP 服务，Agent 可以按需连接和调用这些 Server。MCP 的价值不只是统一接口，更重要的是把认证、权限、审计和工具描述标准化。
提示词精细化
Main Agent 和 Sub Agent 应分别拥有明确的 System Prompt。Main Agent 的 Prompt 负责目标拆解、权限判断、风险控制和结果整合；Sub Agent 的 Prompt 负责局部任务执行、证据保留和格式化返回。
业务规则越复杂，System Prompt 越不能只写角色设定，而要沉淀具体边界、反例、决策规则和输出协议。
什么时候用单 Agent
以下情况应优先使用单 Agent 或工作流：
- 任务能在一次或少数几次工具调用内完成
- 子任务之间强依赖，无法并行
- 输出格式简单，没有复核价值
- 延迟和成本非常敏感
- 团队还没有 Trace、评估和权限治理能力
- 多 Agent 只是为了模拟人类组织结构，而不是解决工程问题
如果单 Agent 的失败原因是 Prompt 不清、工具定义差、上下文混乱或评估缺失，直接增加 Agent 数量通常会放大问题。
单 Agent 的边界
单 Agent 适合目标明确、上下文集中、工具数量有限、执行链路不长的任务。它的优势是简单、低成本、易调试。
但当任务出现以下特征时，单 Agent 会变得吃力：
- 上下文过长，模型需要同时记住太多资料
- 工具过多，模型容易混淆能力和参数
- 子任务可以并行，但单 Agent 只能串行执行
- 任务需要互相独立的专业视角
- 结果需要交叉审查或对抗性评估
- 长任务中需要隔离试验分支，避免污染主上下文
多 Agent 的核心价值就是处理这些边界。
什么时候用多 Agent
多 Agent 系统不是把一个任务拆给多个模型同时回答，而是把复杂任务中的角色、上下文、工具权限和责任边界拆开管理。它的价值来自分工、隔离、并行和复核，而不是 Agent 数量本身。
如果任务本来可以由一个 Agent 稳定完成，引入多 Agent 只会增加协调成本、上下文传递损耗和错误来源。多 Agent 只有在复杂度、并行性或治理要求足够高时才值得使用。
1. 任务天然可并行
竞品分析、资料收集、代码仓库扫描和多市场调研都适合并行。不同 Agent 可以分别处理不同来源、模块或地区，最后由 Main Agent 汇总。
Main Agent：定义研究问题和输出结构
-> Sub Agent A：收集官网与产品信息
-> Sub Agent B：收集价格与渠道信息
-> Sub Agent C：收集用户评价与媒体报道
-> 汇总 Agent：去重、比对、形成结论并行能降低总耗时，但前提是子任务之间依赖少，输出格式统一。
2. 需要专业分工
复杂任务往往包含不同专业能力。例如构建一个数据报告可能需要数据分析、行业研究、可视化和编辑审稿。让一个 Agent 同时承担所有角色，会让 Prompt 复杂、上下文拥挤、标准不清。
| 角色 | 职责 |
|---|---|
| Planner | 拆解任务、分配子任务、跟踪进度 |
| Researcher | 搜索资料、保留来源、提取事实 |
| Analyst | 做比较、归因和数据分析 |
| Writer | 按结构生成报告 |
| Reviewer | 检查事实、逻辑、格式和风险 |
3. 需要上下文隔离
长任务中，子任务会产生大量中间资料。如果全部放入 Main Agent，上下文会迅速膨胀。Sub Agent 可以在独立上下文中处理细节，只把结论、证据和风险返回给 Main Agent。
这种方式能减少主上下文污染，也能降低 token 成本。
4. 需要独立复核
对于代码修改、法律合规、财务分析、医疗辅助等高风险场景，可以让一个 Agent 执行，另一个 Agent 审核。审核 Agent 不应共享执行 Agent 的全部思路，而应基于输出、证据和规则独立判断。
5. 需要探索多个路径
开放问题往往有多种可行路径。多个 Agent 可以分别探索不同方案，再由评估器比较成本、风险和收益。适合策略制定、架构选型、产品方案和复杂排错。
多 Agent 常见协作模式
1. 主从模式
Main Agent 负责任务拆解、子任务分派和结果整合。Sub Agent 只处理局部任务。
Main Agent
-> Sub Agent 1
-> Sub Agent 2
-> Sub Agent 3
-> Synthesis这是最常用、最容易治理的模式。关键是子任务要有清晰输入、输出格式和完成标准。
2. 并行研究模式
多个 Agent 同时从不同来源收集信息，汇总 Agent 负责去重、排序和引用校验。适合 Deep Research、竞品分析和舆情监测。
3. 评审模式
一个 Agent 生成方案，另一个 Agent 按规则审查。审查结果可以返回给生成 Agent 修订，也可以交给人工确认。
Generator -> Reviewer -> Revision -> FinalReviewer 的 Prompt 要包含明确标准，例如事实准确性、约束满足、引用完整性、安全风险和输出格式。
4. 辩论模式
多个 Agent 分别提出不同观点，再由裁判 Agent 评估。它适合高价值决策，但成本高，也容易变成形式化争论。工程上要限制轮次和评价标准。
5. 黑板模式
所有 Agent 读写同一个共享工作区。它适合复杂协作，但需要严格管理文件命名、状态锁、版本和冲突处理。
多 Agent 设计
上下文设计
多 Agent 系统最容易失败的地方是上下文传递。Main Agent 给 Sub Agent 的输入过少，Sub Agent 会偏题；输入过多，又会削弱隔离效果。
子任务上下文应包含：
- 任务目标
- 输入资料或可访问资源
- 可用工具和权限
- 输出格式
- 完成标准
- 禁止事项
- 返回时需要报告的风险
Sub Agent 返回结果时，不应只返回最终答案，还应返回证据、假设、失败项和需要 Main Agent 决策的问题。
子任务返回格式：
- 结论
- 关键证据
- 来源链接或文件
- 不确定项
- 已尝试但失败的路径
- 建议下一步工具、权限与记忆隔离
多 Agent 不应该默认共享全部工具。不同角色应获得不同工具权限。
| Agent 类型 | 建议权限 |
|---|---|
| Researcher | 搜索、读取网页、读取文档 |
| Coder | 读取文件、编辑文件、运行测试 |
| Reviewer | 读取文件、查看 Trace、运行检查，默认不写入 |
| Operator | 调用业务 API，但高风险动作需要确认 |
| Planner | 分派任务、读取摘要，通常不直接执行高风险工具 |
多 Agent 系统也需要共享记忆，但不能无差别共享上下文。推荐使用三类存储：
- 主任务状态：由 Main Agent 维护，记录目标、约束、进度和决策
- 子任务工作区：Sub Agent 独立使用，保存中间资料和临时产物
- 长期经验记忆：保存可复用策略、失败教训和业务规则
共享记忆要记录版本和来源。多个 Agent 写入同一事实时，系统需要记录谁写入、基于什么证据、何时写入、是否被后续覆盖。
评估方法
多 Agent 系统不能只评估最终答案，还要评估协作过程。
| 指标 | 关注点 |
|---|---|
| 子任务正确率 | 每个 Agent 是否完成了分配任务 |
| 汇总质量 | Main Agent 是否正确整合结果 |
| 上下文传递损耗 | Sub Agent 是否遗漏主任务约束 |
| 并行收益 | 多 Agent 是否实际降低总耗时 |
| 成本效率 | 增加 Agent 是否带来可接受收益 |
| 冲突处理 | 不同 Agent 结论矛盾时是否能解决 |
| 安全性 | 权限是否越界，写操作是否可审计 |
评估数据应包含 Trace：任务分派、Sub Agent 输入、工具调用、子任务输出、Main Agent 汇总和最终回复。没有这些数据，就无法判断多 Agent 是否真的有效。
参考资料
正在检查阅读权限…