AskAric
← 返回 Posts

模型越来越强，Agent 的长期价值不在补脑，而在系统

当模型持续变强，真正长期有价值的 Agent，不是替模型补齐“通用脑力”，而是把模型放进一套可执行、可积累、可治理的系统里。本文把 Prompt、Context、Knowledge、Skill、Workflow 和 Orchestration 的边界拆开讲清楚。

2026年3月12日•aric
Agent
大模型
AI Engineering

过去两年，围绕大模型的讨论，已经明显换了一个重心。

最早大家关心的是：模型会不会回答问题，会不会写代码，会不会总结文章。现在问题变成了另一种：它能不能真的把一件事做完。

也正因为这样，Agent 开始变成一个高频词。有人做 Skills，有人做 Workflow，有人做多 Agent，有人做记忆，有人做工具调用，也有人试图把一切都继续塞进更长的 Prompt。

但如果模型本身还会持续变强，那么今天做 Agent，什么是长期资产，什么只是阶段性脚手架？

模型会继续变强，几乎已经是行业共识。真正拉开差距的，不会是谁更会写 Prompt，而是谁更早把模型放进了一套能做事、能积累、能治理的系统里。

我现在越来越倾向于一个判断：

未来真正有价值的 Agent，不是继续替模型补脑，而是把模型放进一套可执行、可积累、可治理的系统里。

这篇文章想讲清楚的，就是这条边界：什么该交给模型，什么该交给系统。

1. 先拆误区：Agent 不是更复杂的 Prompt

很多 Agent 做着做着会变形，路径通常都很像。

一开始只是想让模型稳定一点，于是加规则。后来怕它漏步骤，又加流程。再后来怕它调用错工具，于是把调用顺序、异常处理、输出格式、固定措辞、兜底策略全部塞进去。

最后你会得到一个看起来“很完整”的 Prompt，但它其实已经偷偷承担了太多职责：

  • 既想充当角色设定
  • 又想充当知识库
  • 还想兼任流程引擎
  • 甚至顺手把工具策略和评测规则也包了

问题不在于 Prompt 不重要。问题在于 Prompt 不是万能胶。

Prompt 很适合定义方向、身份、边界、语气，也很适合告诉模型“这类问题大概应该怎么理解”。但它并不适合同时承担知识供给、流程推进、工具治理、状态管理和评测闭环这些系统工作。

一旦这些东西都揉进 Prompt，系统表面上像是“更聪明了”，实际上会更脆：

  • 规则一多，维护成本迅速上升
  • 一个局部改动，可能影响整段行为
  • 你很难知道问题究竟出在模型、知识、工具还是流程

这也是为什么很多团队做了一段时间 Agent 之后，会产生一种失望感。不是方向没价值，而是系统从第一天就没有分层。

这一节的结论： 从 Anthropic 对 agent 的定义，到 OpenAI 对 agent builder 的拆法，Prompt 都只是 agent 的一部分，不是 agent 本身；把知识、流程、工具策略和评测都塞进 Prompt，只会让系统更脆。（参考：Anthropic, Building effective agents、OpenAI, Agent Builder）

2. 划清边界：最先会被模型吃掉的是“通用脑力补丁”

如果模型还会继续变强，那最先被吞掉的，通常不是系统层，而是那些本来就属于“通用脑力”的补丁。

比如：

  • 把一句话改写成更规范的需求
  • 从一堆材料里抓重点
  • 输出一份像样的摘要或报告
  • 做浅层规划和分解
  • 在常见场景里给出基本可用的判断

这些能力本来就是模型天然会持续增强的方向。

所以，如果一个 Agent 的主要价值，仍然停留在下面这些事情上：

  • 替模型多理解一点上下文
  • 替模型重写一下用户输入
  • 替模型补一层很浅的规划
  • 用一堆提示词把模型“扶正”到常识水平

那它的生命周期大概率不会太长。

这里要强调一句：这不是论文里的硬结论，而是基于模型演进路线的工程判断。

从最近几代模型的公开定位看，通用推理、编码、多步执行和 agentic workflow 都在持续上移。也就是说，越是“通用脑力型”的补丁，越容易被下一代模型自然吸收掉。

所以，今天做 Agent 最不划算的一件事，就是把大量工程投入放在“替模型补通用脑力短板”上。

这一节的结论： 只要一个 Agent 的主要价值还停留在“帮模型多理解一点、重写一下、浅规划一下”，它就更容易被下一代模型直接吞掉；这是基于 GPT-5 和 Claude Opus 都在持续强化通用推理、编码和多步执行能力做出的工程判断。（参考：OpenAI, Introducing GPT-5 for developers、Anthropic, Claude Opus）

3. 真正不会过时的，是系统层

和“通用脑力补丁”相对的，是另一类问题。

这类问题不会因为模型更强就自动消失。相反，只要你想让模型进入真实世界，它们就一定会越来越重要。

比如：

  • 它应该从哪里拿信息
  • 当前任务到底该给它什么上下文
  • 哪些工具可用，哪些工具有副作用
  • 哪些动作必须审批，哪些动作可以自动执行
  • 任务做到一半时，状态怎么保存
  • 多个阶段之间怎么切换
  • 失败之后怎么回放、怎么追责、怎么复盘
  • 同类问题下次怎么更稳地做对

这些问题本质上都不是“模型智力”问题，而是系统问题。

而且模型越强，系统层反而越重要。原因很简单：

  • 模型越强，越可能被接入真实生产环境
  • 场景越真实，权限、审计和证据链越重要
  • 风险越高，审批、回放和评测就越不能省

所以我现在越来越觉得，Agent 真正该做的，不是继续造一个更复杂的大脑，而是把大脑之外那套能落地做事的系统补齐。

这一节的结论： 进入真实世界以后，信息获取、权限边界、状态管理、审批、追踪、回放和评测，都是系统问题，不是“模型更聪明一点”就会自然消失的问题。（参考：Anthropic, Building effective agents、OpenAI, Agents SDK、OpenAI, Safety best practices for building agents、Anthropic, Demystifying AI agent evals）

4. 把 Agent 拆开看：八层分工，很多问题就顺了

如果把一个 Agent 系统拆开看，它至少可以分成八层。

  1. 模型：负责理解、推理、判断、表达
  2. 上下文：负责把当前任务真正需要的信息给到模型
  3. 知识：负责提供事实、规则、背景、经验
  4. 技能：负责沉淀可复用的方法包
  5. 工具：负责真正去查、去读、去跑、去改
  6. 流程：负责回答“先做什么，后做什么”
  7. 编排：负责切换阶段、调度能力、处理审批与结束条件
  8. 评测与反馈：负责让系统从“一次做出来”变成“长期做稳定”

模型只是其中一层，而且不是唯一核心。

一旦分层清楚，很多争论会自动变简单：

  • 某段内容应该写进 Prompt，还是放进知识库？
  • 是该做成一个 Skill，还是拆成多个 Tool？
  • 这是流程问题，还是编排问题？
  • 这件事是靠模型自己判断，还是靠系统加审批？

下面这张图，可以把分工看得更直观一点：

flowchart TB
  U["用户任务"] --> G["目标<br/>这件事要做到什么程度"]
  G --> M["模型<br/>理解、推理、判断、表达"]
  M --> C["上下文<br/>当前任务所需信息"]
  M --> Memory["记忆<br/>历史状态与中间结果"]
  M --> K["知识库<br/>规则、经验、文档"]
  C --> O["编排<br/>调度、切换、审批、追踪"]
  Memory --> O
  K --> O
  O --> W["流程<br/>任务推进顺序"]
  O --> S["技能<br/>可复用方法包"]
  O --> B["边界<br/>权限与风险约束"]
  W --> T["工具<br/>日志、数据库、API、终端"]
  S --> T
  B --> T
  T --> E["真实环境<br/>代码、系统、数据、用户"]
  E --> F["评测与反馈<br/>复盘、回归、持续优化"]

这一节的结论： 把模型、上下文、知识、技能、工具、流程、编排、评测分层之后，很多“到底该写进 Prompt 还是写进系统”的问题会自动变清楚。（参考：Anthropic, Effective context engineering for AI agents、Anthropic, Building effective agents、OpenAI, Agent Builder）

5. 最容易混的三组词

知识不是技能

最简单的区分是：

  • 知识回答的是“知道什么”
  • 技能回答的是“怎么做”

知识更像材料，技能更像工法。

比如在数据库排障里：

  • “TiDB、TiKV、PD 各自负责什么”是知识
  • “遇到慢查询时，先看 slow log，再看执行计划，再归因”是技能

知识提供判断依据，技能组织行动路径。两者会互相依赖，但不应该混成一坨。

Tool 不是 Skill

如果再往下拆，Tool 和 Skill 也不是一回事。

我的建议是这样理解：

  • Tool 更像最小动作
  • Skill 更像围绕某类任务组织起来的方法包

例如：

  • “查最近 30 分钟日志”是 Tool
  • “做一次性能分诊”更像 Skill

前者是一个动作，后者是一组动作、判断和产出的组合。

Workflow 也有上下两层

很多人说 Workflow，其实在说两种不同的东西。

一种是任务级流程，比如：

  1. 接收问题
  2. 初步分诊
  3. 收集证据
  4. 验证假设
  5. 输出结论
  6. 必要时升级或审批

另一种是技能内部步骤，比如“分析慢查询”这个 Skill 里面，又会有自己的顺序：

  1. 看 slow log
  2. 看执行计划
  3. 判断是不是统计信息或索引问题
  4. 输出结论

所以更准确的看法不是“Workflow 就是一张图”，而是：

  • 上层管全局推进
  • 下层管局部工法

这一节的结论： 知识更像材料，技能更像工法；Tool 更像最小动作，Skill 更像围绕任务组织起来的方法包；Workflow 既有任务级推进，也有技能内部步骤。这套拆法是对 RAG、tool use 和 orchestration 文献与工程实践的归纳，不是词汇游戏。（参考：RAG、ReAct、Toolformer、Anthropic, Writing effective tools for AI agents、OpenAI, A practical guide to building AI agents）

6. 为什么 Context Engineering 会越来越重要

过去很多人以为，只要把第一句 Prompt 写好，系统自然就会稳。

真正做过长任务、多步任务、工具任务之后，很快就会发现，问题根本不在这儿。

真正影响结果的，往往不是第一句 Prompt 写得多漂亮，而是：

  • 现在到底该给模型什么信息
  • 哪些历史内容该压缩，哪些必须保留
  • 哪些工具当前可用
  • 当前阶段的完成条件是什么

也就是说，Prompt Engineering 更像“怎么说”，而 Context Engineering 更像“怎么把工作台搭对”。

这一点在多步任务里尤其明显。因为上下文一旦失控，模型会马上出现几种典型问题：

  • 看到的信息太多，抓不到真正重点
  • 重要信息埋在中间，反而利用不好
  • 不该拿到的信息提早进入上下文，造成噪音

所以真正好的 Agent，不是单纯把上下文做大，而是让上下文始终贴着任务走。

这一节的结论： 多步任务真正决定效果的，往往不是第一句 Prompt 写得多漂亮，而是模型在执行过程中能不能持续拿到对的信息；上下文不是越多越好，而是越贴任务越好。（参考：Anthropic, Effective context engineering for AI agents、Lost in the Middle）

7. 为什么组织知识仍然必须外部化

模型会越来越懂通用知识，这点几乎不用怀疑。

但组织里真正关键的知识，很多根本不属于“通用智力”。它们更像组织当前的运行状态，比如：

  • 内部 runbook
  • 最新规则和审批边界
  • 某个客户的特殊环境
  • 某个版本的已知坑
  • 哪些结论必须留证据和引用

这类信息天然有四个要求：

  • 要能更新
  • 要能追踪
  • 要能审计
  • 要能分权限

只要还存在这四个要求，它们就不该只存在模型权重里。

所以，知识外部化不会因为模型变强而失去意义。恰恰相反，模型越强，越值得把真正重要的组织知识从“模型也许知道”变成“系统明确提供”。

这一节的结论： 通用知识会越来越被模型吸收，但组织知识不会因此消失；只要信息需要更新、追踪、审计、分权，它就不该只存在权重里。（参考：RAG、Anthropic, Effective context engineering for AI agents、OpenAI, Agent Builder）

8. 放进数据库排障场景，边界会更清楚

拿数据库排障来说，模型天然适合做很多工作：

  • 看懂告警和现象描述
  • 先做一轮分类和分诊
  • 从日志、指标、执行计划里提炼重点
  • 输出 incident summary
  • 给出几个可能方向

这些事情很适合由模型、知识层和技能层协同完成。

但真实场景里，另一批问题并不会因为模型更聪明就自动解决：

  • 哪些环境能查，哪些环境不能查
  • 哪些工具只读，哪些工具带副作用
  • 哪些动作必须人工批准
  • 哪些结论必须保留证据链
  • 同类故障下次怎么复用经验

所以如果你要做一个数据库排障 Agent，真正该花时间搭的，不是继续写一大段“像资深 DBA 一样思考”，而是把下面这些东西做扎实：

  • 工具入口和权限模型
  • 状态管理和中间结果保存
  • 组织知识供给
  • 审批边界
  • 技能模块
  • 回放与评测

这部分才是长期资产。

这一节的结论： 领域 Agent 的长期资产，不是“像资深 DBA 一样思考”这种大段话术，而是工具入口、状态管理、组织知识、审批边界、技能模块和评测回放这些系统能力。（参考：Anthropic, Writing effective tools for AI agents、OpenAI, Safety best practices for building agents、Anthropic, Demystifying AI agent evals）

9. 如果今天开始做 Agent，最容易走错哪几步

我现在最警惕四种走法。

第一，把大量精力花在补模型短板上

这部分最容易被下一代模型吞掉。

第二，把所有东西都揉进 Prompt

短期看像是“更快上线”，长期看几乎一定会变成黑箱。

第三，把 provider 的产品形态当成自己的架构

无论是 ChatGPT、Claude 还是其他 provider，最终呈现给用户的交互界面，背后都有各自的运行时选择。可以借鉴，但不该直接当成自己的系统架构。

第四，一上来就堆多 Agent，却没有评测闭环

复杂度一旦上来，没有评测、没有 traces、没有回放，系统会很快进入“看起来很忙，但不知道哪里错”的状态。

所以更稳的顺序通常是：

  • 先单 Agent
  • 先把工具和上下文做好
  • 再按任务边界补流程和编排
  • 最后用评测决定要不要继续加复杂度

这一节的结论： 更稳的做法不是默认多 Agent，而是先从简单系统起步，再用评测决定复杂度；否则你很容易得到一个复杂、昂贵、又说不清问题出在哪的系统。（参考：Anthropic, Building effective agents、OpenAI, A practical guide to building AI agents、Anthropic, Demystifying AI agent evals）

10. 最后收束：真正不会过时的，是让模型稳定做事的系统能力

模型会继续变强，这几乎不用怀疑。

所以今天做 Agent，最重要的不是追着每一代模型做补丁式优化，而是先想清楚：

  • 哪些能力本来就应该属于模型
  • 哪些能力无论模型多强都应该由系统承担

这条线一旦划清，很多概念就不会再乱。

Skill、Workflow、Knowledge、Context Engineering、Orchestration，这些词真正的价值，不在于把术语说得更花，而在于把分工说清。

如果一定要把全文压成一句话，我现在会这样说：

未来不会过时的，不是那些把模型伪装得更聪明的技巧，而是那些让模型真正能稳定做事的系统能力。

到最后，真正拉开差距的，不是谁写出了更花哨的 Prompt，而是谁更早意识到：

模型只是大脑，Agent 必须是一整套能做事的身体。

最后的结论： 从 Anthropic 和 OpenAI 的 agent 工程文档到 RAG、tool use、evals 这些基础工作，长期价值都在收敛到同一个方向：不是继续给模型补脑，而是把模型放进一套可执行、可积累、可治理的系统里。（参考：Anthropic, Building effective agents、Anthropic, Effective context engineering for AI agents、OpenAI, Agents SDK、RAG）

参考来源

  1. Anthropic, Building effective agents
  2. Anthropic, Effective context engineering for AI agents
  3. Anthropic, Writing effective tools for AI agents
  4. Anthropic, Demystifying AI agent evals
  5. OpenAI, Agent Builder
  6. OpenAI, Agents SDK
  7. OpenAI, Safety best practices for building agents
  8. OpenAI, A practical guide to building AI agents
  9. OpenAI, Introducing GPT-5 for developers
  10. Anthropic, Claude Opus
  11. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
  12. ReAct: Synergizing Reasoning and Acting in Language Models
  13. Toolformer: Language Models Can Teach Themselves to Use Tools
  14. Lost in the Middle: How Language Models Use Long Contexts