Agent 范式演化对比与选型实操教程

一、教程目标:这篇教程要带你完成什么

近几年基础模型能力快速迭代,Agent 领域出现了爆发式增长,新一代以编码助手为代表的产品与框架不断涌现,能力相比早期版本有明显跃升。但技术演进不是线性平滑的,而是分阶段跳跃的——早期教程里学到的很多概念,今天要么被重新定义,要么已被更工程化的方案吸收。

因此本教程的目标不是介绍某个具体产品,而是交付一套可操作的范式对比与选型方法:

1. 用统一的维度坐标系,描述任意一套 Agent 方案的架构位置;
2. 把 2023—2026 年的四个演化阶段拆成”变化点 + 变化原因”,而不是记住一堆名词;
3. 针对你的业务场景,做出一份有依据的技术选型结论,并完成配置与验证;
4. 建立评测与可观测体系,让”换个新架构更好”变成可量化的事实,而不是感觉。

需要强调原文中的一个关键判断:演化前后的范式并非简单替代关系,很多能力可以组合使用。所以本教程最终交付物是”混合架构”,而不是”全面替换”。

二、适用读者与适用场景

读者	关注重点
Agent 应用开发者	控制流实现方式、上下文组织、工具接入、失败恢复
算法/模型工程师	模型分层路由、评测集构建、提示与上下文预算
运维与 SRE	超时重试、限流、可观测性、成本告警
技术负责人	选型依据、迁移风险、投入产出、演进节奏

适用场景:智能客服与工单处理、企业内部知识问答、数据分析与报表生成、运维排障助手、编码与代码审查助手、跨系统流程自动化(RPA 类任务的智能化替代)。

不适用场景:强确定性、规则完备、无需自然语言理解的固定流程——这类需求用传统工作流或规则引擎成本更低,引入 Agent 反而增加不确定性。

三、前置准备

知识准备

• 理解大模型的基本调用方式:提示词、上下文窗口、流式输出、结构化输出、函数调用(function calling)的基本概念;
• 了解检索增强生成(RAG)的基本链路:切分、向量化、召回、重排、拼接;
• 了解基本的分布式服务概念:超时、重试、幂等、限流、熔断。

环境准备

• 一个可调用的大模型服务端点(可使用百度智能云的大模型服务能力,或任意主流云服务商的模型服务);
• 对象存储(存放文档与中间产物)、日志服务(存放调用链路)、监控告警(指标与阈值)、消息队列(异步任务解耦)等通用云产品类目,按需在云服务控制台开通;
• 一套可版本化管理的代码仓库与配置中心,用于管理提示词、工具描述与编排定义;
• 若要执行真实工具调用(数据库、工单系统、文件系统),准备独立的测试环境与最小权限账号。

数据准备(最容易省略、也最不能省)

• 离线评测集:30—100 条来自真实业务的输入样本,每条包含输入、期望行为、验收判据。这是后续所有”新旧对比”的唯一可信依据;
• 工具清单:每个工具的名称、语义、入参 schema、副作用等级(只读/写入/不可逆)、平均耗时。

四、先建坐标系:四阶段演化到底变了什么

下面把四年演进归纳成四个阶段。这是行业趋势的归纳性划分,具体产品实现各有差异,不要当作某家的官方版本号。

阶段一(2023):概念启蒙期 —— 以”规划”为中心的自主循环

早期被广泛引用的经典架构可以概括为四要素:大模型 + 规划(Planning) + 工具(Tools) + 记忆(Memory)。

• 控制流:模型自己决定下一步做什么,循环”思考 → 行动 → 观察”,直到认为任务完成;
• 上下文:全部塞进一个对话历史里,靠模型自己维持;
• 工具:以自然语言描述 + 文本解析为主,参数抽取靠模型”猜”;
• 记忆:基本等价于对话历史,没有分层。

局限:循环无法收敛(反复调用同一工具)、长任务上下文爆掉、工具参数幻觉、失败无法定位。这些问题不是模型不够聪明,而是架构缺少约束。

阶段二(2024 前后):工作流化 —— 把不确定性关进笼子

工程侧的应对是把控制权从模型手里收回来一部分:用有向图/状态机显式编排节点,把”路由、分支、循环上限、重试”写成代码;工具调用从文本解析升级为结构化参数模式(schema)约束,由运行时校验后再执行;检索从”一次性拼接”升级为多路召回 + 重排 + 分块按需注入。

变化原因:业务要的是可交付的成功率,而不是”看起来智能”。确定性流程用确定性编排,是成本最低的解法。

阶段三(2025 前后):上下文工程 —— 竞争焦点从”提示词”转向”上下文”

当模型能稳定遵循复杂指令后,瓶颈转移到了给模型看什么。这一阶段的标志性变化:

• 上下文成为一等公民:区分系统指令、任务目标、检索证据、工具结果、历史摘要,并显式管理每一部分的预算;
• 压缩与摘要机制:长历史滚动摘要、工具结果裁剪、按相关性淘汰;
• 记忆外置:把长期记忆放到外部存储(向量库、结构化数据库、文件),按需检索,而不是全程携带;
• 子智能体分解:主智能体负责规划与整合,子智能体在隔离开上下文中执行子任务,只回传结论,避免主上下文被中间过程污染。

变化原因:任务变长、工具变多,单上下文线性膨胀必然触发成本与效果的双重衰减。

阶段四(2026 前后):产品化与治理 —— 从”能跑”到”可运营”

新一代编码助手类产品代表的方向是把 Agent 当软件工程系统来做:

• 可观测:全链路追踪(trace)记录每一步的模型调用、工具入参出参、耗时与 token;
• 可评测:回归评测集 + 自动打分,任何提示或模型变更都跑一遍;
• 安全边界:工具权限分级、沙箱执行、写操作二次确认、敏感信息脱敏;
• 成本治理:模型分层路由(简单步骤用小模型)、结果缓存、并发与预算控制。

变化原因:Agent 从 Demo 走向生产,决定成败的不再是峰值能力,而是 P95 稳定性与单位任务成本。

五、实施步骤:做一次完整的范式选型与落地

步骤 1:定义任务边界与验收判据

先回答三个问题:任务输入是什么?什么算完成?不做什么?

把验收判据写成可自动判定或可人工快速判定的形式,例如:

task: 根据用户自然语言查询生成月度经营数据摘要
input: 自然语言问题 + 时间范围
done_when:
  - 输出的每个数字都能追溯到一次数据查询结果(可追溯率 = 100%)
  - 涉及的指标口径与指标字典一致
  - 单次任务 P95 延迟 < 20s
not_in_scope: 不执行任何写库操作;不回答口径未定义的指标

为什么先做这一步:没有判据,后面所有对比都只能凭观感,这也是”盲目追求最新架构”的根源。

步骤 2:用统一维度给候选方案打标签

对每个候选架构,填写下表。这一步依赖步骤 1 的判据,因为维度的权重由判据决定。

维度	取值示例	需要问的问题
控制流归属	模型自主 / 代码编排 / 混合	循环终止条件由谁保证?
上下文策略	全量携带 / 分层 + 压缩 / 外部检索	上下文超限时如何降级?
工具接入	文本解析 / schema 约束 + 运行时校验	非法参数如何拦截?
记忆位置	对话内 / 外部存储	跨会话如何复用?
任务分解	单智能体 / 主子智能体	子任务结果如何回传?
失败恢复	重试 / 回退到上一检查点 / 人工接管	幂等键是什么?
可观测粒度	请求级 / 步骤级 / token 级	能否还原一次失败?

步骤 3:按任务特征做选型(决策清单)

按以下顺序判断,通常前三步就能定下主架构:

1. 步骤可枚举、结果需稳定 → 以确定性工作流为主干,只在”需要理解的分支节点”引入模型判断(阶段二范式);
2. 输入长尾多、步骤无法预先枚举 → 自主循环为主,但必须加循环上限、步骤预算与结构化输出校验(阶段一内核 + 阶段二/四护栏);
3. 依赖大量企业知识 → RAG 与上下文工程为底座,不要靠微调硬灌知识(阶段三范式);
4. 任务需要跨多个系统读写 → 主子智能体 + 工具权限分级 + 沙箱,写操作必须显式确认(阶段四范式);
5. 延迟或成本敏感 → 模型分层路由 + 结果缓存 + 缩短上下文,而不是换更大的模型。

常见错误:所有任务都用同一个”全能自主 Agent”。正确做法是按任务类型分路,不同路由用不同范式。

步骤 4:分阶段落地与灰度

顺序不能颠倒:

离线评测(可重复、零风险)
  → 影子运行(真实流量,结果不生效,只对比)
    → 小流量灰度(按用户或租户维度)
      → 全量

每一级都以上一级的指标不劣化为进入条件。跳过离线评测直接灰度,是迁移项目翻车最常见的原因。

步骤 5:建立评测与可观测

至少采集这些指标:

• 任务级:成功率、人工接管率、P50/P95 延迟、单任务 token 与费用;
• 步骤级:平均迭代轮数、工具调用成功率、参数校验失败率、上下文压缩触发次数;
• 系统级:模型服务错误率、限流次数、队列积压。

日志用 trace_id 串起一次完整任务,并写入日志服务,配合监控告警设置阈值。

六、配置说明:关键参数的含义、取值逻辑与风险

以下为通用示意配置项(键名仅为示例,请以你所选框架的实际文档为准):

配置项	含义	取值逻辑	风险
max_iterations	自主循环最大轮数	取离线评测中成功样本轮数的 P95,再留 20% 余量	过小会截断长任务;过大会放大成本与失控风险
context_budget_tokens	单次模型调用上下文预算	按模型窗口的 60%—70% 设置,留出输出与系统开销	贴满窗口会显著降低指令遵循质量
tool_timeout_ms	单个工具调用超时	取工具耗时的 P99	过长会拖垮整体延迟;过短会误判失败
retry_policy	重试次数与退避	仅对幂等只读工具重试,写操作默认不重试	对非幂等写操作重试会造成重复业务动作
max_parallel_subagents	子智能体并发上限	由下游系统限流阈值反推	并发过高触发下游限流,引发连锁失败
memory_write_policy	长期记忆写入策略	只写”已确认结论”,不写中间推理	写入错误结论会长期污染后续任务
model_routing	模型分层路由规则	按步骤复杂度分级:分类/抽取用小模型,规划/整合用强模型	分级过粗会让难任务走小模型,效果塌陷
tool_permission_level	工具权限分级	只读免确认;可逆写入需记录;不可逆操作需人工确认	权限过宽是 Agent 类系统最大安全隐患

配置风险总原则:凡是”限制类”参数(轮数、并发、超时、权限)都应偏保守,并在压测中验证边界行为,而不是取中间值。

七、示例说明:两种范式的通用伪代码

早期范式:以模型自主循环为核心

def agent_loop(task, tools, memory, cfg):
    ctx = [system_prompt(), task]
    for i in range(cfg.max_iterations):
        resp = model(ctx + memory.recent(), tools=tool_specs(tools))
        if resp.is_final:                      # 依赖模型自己判断"做完了"
            return validate(resp.answer)
        try:
            args = parse_args(resp.text)       # 文本解析,易幻觉
        except ParseError:
            ctx.append(hint_repair_args(resp.text))
            continue
        if not tools[resp.name].schema.valid(args):
            ctx.append(hint_schema_error(args)); continue
        obs = tools[resp.name].call(**args)    # 直接执行,无权限分级
        ctx.append(obs)
        memory.append(obs)                     # 记忆 = 全部历史
    return Failure("max_iterations_exceeded")  # 唯一收敛保障是轮数

新一代范式:混合编排 + 上下文工程 + 治理护栏

def hybrid_agent(task, cfg):
    plan = planner(task)                        # 显式规划,产出结构化步骤
    ctx = ContextBudget(cfg.context_budget_tokens)
    ctx.add_system(instructions())
    ctx.add_task(task)
    results = []
    for step in plan.steps:                     # 控制权在代码,不在模型
        if step.kind == "deterministic":
            out = workflow.run(step.graph)      # 确定性节点直接编排
        elif step.kind == "retrieve":
            out = retriever.search(step.query, k=cfg.top_k, rerank=True)
            out = ctx.compress(out)             # 证据按需注入 + 裁剪
        else:
            out = sub_agent.run(                # 子智能体隔离上下文
                goal=step.goal,
                tools=filter_tools(step, level=cfg.tool_permission_level),
                on_result=lambda r: results.append(r.summary())  # 只回传结论
            )
        if step.side_effect == "irreversible" and not step.confirmed:
            return await_human_confirm(step)    # 高风险操作人工确认
        ctx.add_evidence(out)
    answer = integrator(ctx.render())           # 最后统一整合
    return validate_and_trace(answer)           # 校验 + 全链路埋点

两者对比的关键差异:早期范式用轮数兜底,新一代范式用编排、预算、权限、校验四层兜底;早期范式把过程全塞进上下文,新一代范式让子智能体消化过程、只回传结论。

八、结果验证:怎么判断真的跑通了

分三层验收,任一层不达标都不进入下一层:

层级一:组件正确性

• 工具 schema 校验能拦截故意构造的非法参数;
• 检索链路在评测集上的召回命中率达标(可用”是否包含正确答案依据”人工标注);
• 结构化输出解析失败率低于设定阈值。

层级二:任务级效果

• 离线评测集成功率不低于原方案;
• 平均迭代轮数下降或持平(下降说明护栏生效);
• 人工接管率可解释:每个接管样本都能归因到具体环节。

层级三:系统级稳定性

• 连续压测下 P95 延迟与错误率符合阈值;
• 注入故障(工具超时、模型返回异常、下游限流)时,系统按预期降级而非崩溃;
• 成本可预测:单任务费用分布的 P95 在预算内。

推荐做法:把新旧方案在同一评测集上做影子对比,输出一张对照表(成功率、延迟、成本、人工接管率)。这张表就是选型的最终交付物。

九、常见问题与排查

现象	可能原因	排查思路
反复调用同一工具,循环打转	缺少状态去重与循环终止条件;观察结果未被有效注入	打印每轮动作指纹;加入”重复动作检测”并强制换路或终止
上下文越长效果越差	全量携带历史,关键信息被稀释;超出有效注意力范围	做上下文消融:固定任务,逐步裁剪各段,观察成功率变化
工具参数幻觉	工具描述语义模糊、参数约束缺失、示例不足	收紧 schema,补充字段说明与正反示例,加入运行时校验与纠错重试
迁移后效果回退	提示或上下文结构变更未走评测;新旧逻辑混跑产生冲突	用回归评测集定位回退样本,二分对比新旧提示与编排
成本突然飙升	循环轮数失控;子智能体并发过高;未使用缓存与分层路由	按 trace 拆解 token 分布,定位消耗最大的步骤
写操作重复执行	非幂等接口 + 无差别重试	引入幂等键;写操作关闭自动重试并改为查询确认
评测分数高但线上差	评测集与真实分布不一致	从线上日志回捞困难样本,持续扩充评测集

十、优化建议

性能:把高频、确定性步骤从模型路径上摘出去;对可缓存结果加缓存键(输入归一化后哈希);子任务并行化但受并发上限约束;检索侧优先提升召回质量而非单纯放大 top-k。

成本:模型分层路由是收益最高的一项;按步骤统计 token,优先优化消耗 Top3 的步骤;长上下文改用摘要 + 按需展开。

安全:工具权限最小化;不可逆操作强制人工确认;敏感字段在写入日志前脱敏;工具执行放沙箱,限制文件系统与网络访问范围;对模型输出的代码或命令不直接执行。

稳定性:所有外部调用设超时与退避重试;下游限流时排队而非丢弃;保留”降级到确定性流程”的通路;关键任务支持断点续跑。

可维护性:提示词、工具定义、编排配置全部版本化,与代码一起评审;建立变更后必跑评测的门禁;把 trace 保留足够周期以支持事后归因。

十一、需要避开的三个误区

1. 为升级而升级:如果现方案在评测集上已达标,重构只带来风险。升级必须由指标驱动。
2. 盲目追求最新概念:名词本身不产生收益,”是否解决了你当前瓶颈”才是判断标准。
3. 把新旧范式当互斥选项:确定性工作流提供收敛保障,自主循环提供长尾覆盖,上下文工程提供信息质量,治理层提供生产可用性——四者叠加通常优于任何单一范式。

十二、总结

本教程交付了一条完整路径:定义判据 → 统一维度打标签 → 按任务特征选型 → 分阶段灰度 → 建立评测与可观测 → 按问题排查调优。

核心结论有三点:第一,Agent 的四阶段演化本质是控制权在模型与代码之间反复重新分配的过程,早期用模型自主换灵活性,中期用编排换确定性,后期用上下文工程换信息质量,现在用治理层换生产可用性;第二,新旧范式是分层组合关系,不是替代关系;第三,任何架构决策都必须落在你自己的评测集上验证。

后续可继续深入的方向:工具生态的接入规范与权限模型、长任务的记忆分层与检索策略、多智能体协作的通信开销控制、Agent 系统的评测方法论(尤其是难以自动判定的开放式任务如何打分)。在基础设施层面,可直接使用百度智能云的模型服务能力,配合对象存储、日志服务、监控告警等通用产品类目构建完整的 Agent 运行时,避免自建可观测与存储链路带来的额外成本。