普通的大模型应用，本质上还是：

用户 → Prompt → LLM → Answer

你问一句，它回答一句。

哪怕回答得再聪明，它仍然只是一个信息处理系统。

Agent 则不一样。

它的基本结构更接近：

目标 → 判断下一步 → 调用工具 → 获得结果 → 再判断 → 再行动 → 直到任务完成

Anthropic 对 Agent 的描述也非常接近这个思路：Agent 不只是生成内容，而是能够在多轮运行中使用工具、修改环境状态，并根据中间结果继续调整自己的行为。

比如一句很简单的话：

“帮我研究三家公司的 Agent 产品，然后写一份竞争分析。”

对于 Chatbot 来说，它可能直接根据已有知识生成一篇回答。

但真正的 Agent 可能需要：

搜索公司资料 → 判断来源可信度 → 打开网页 → 提取信息 → 发现资料不足 → 再次搜索 → 对比产品 → 整理数据 → 写报告 → 检查遗漏 → 修改 → 输出最终结果。

所以 Agent 与普通 LLM 应用最大的区别，并不是多了一个“Agent”按钮。

而是：

AI 开始拥有一个持续行动的循环。

LLM 开始从一个“答案生成器”，变成一个“任务执行者”。

而事情也正是在这里开始变复杂。

因为让模型调用一次工具并不困难。

真正困难的是：

怎么保证它连续工作几十步之后，依然没有把事情搞砸。

假设一个 Agent 正在执行任务。

它可能搜索错资料。

可能调用错误的工具。

可能重复执行同一个步骤。

可能陷入死循环。

可能上下文越来越长。

可能 Token 成本不断上涨。

可能把一个简单问题交给最昂贵的模型。

也可能在执行到第十五步的时候，忘记自己第一步到底要解决什么。

更麻烦的是，它的行为路径并不是完全确定的。

传统软件通常是：

if A:
    do B
else:
    do C

工程师提前定义好了绝大部分路径。

Agent 更像：

Goal
 ↓
LLM 判断下一步
 ↓
Action
 ↓
Environment Result
 ↓
LLM 再判断
 ↓
Action
 ↓
……

连执行路径本身都是运行过程中生成的。

所以开发 Agent，不再只是“写程序”。

你实际上是在设计一个环境，让一个具有概率性和自主性的智能体在里面工作。

这就是 Agent Engineering 真正出现的原因。

这也是我最近越来越明显的一个感受。

之前我分别研究过 RAG、Router、Redis/Cache、Evals、Harness。

当时看起来，它们像几项互相独立的 AI 技术。

但如果站在 Agent Engineering 的角度重新看一次，它们的位置突然变得非常清楚。

RAG：Agent 应该知道什么？

我之前在讨论 RAG 时，用过一个我很喜欢的比喻：

RAG 做得不好，模型再强也没用。秘书如果拿错了资料，老板再聪明也很可能答错。

到了 Agent 时代，这句话反而更加重要。

因为 Agent 每一次行动，本质上都建立在它当前拿到的信息之上。

所以 RAG 解决的是：

Agent 在做决定之前，应该拿到什么资料？

它属于更大的 Context Engineering。

Anthropic 也把 Context Engineering 看作 Prompt Engineering 的进一步扩展：工程问题已经不只是“Prompt 应该怎么写”，而是每一次模型推理之前，到底应该把哪些 instructions、历史信息、外部数据、工具描述和状态放进有限的 Context Window。

于是 AI 工程逐渐经历了一个很有意思的变化：

Prompt Engineering

↓

Context Engineering

↓

Agent Engineering

范围越来越大。

MCP / Tools：Agent 能做什么？

光知道东西还不够。

Agent 真正和 Chatbot 拉开差距，是因为它可以行动。

读数据库、查网页、操作文件、执行 Python、调用企业系统、发送信息……

这些能力都需要 Tools。

而 MCP 解决的正是 Agent 与大量外部工具和数据源之间的标准化连接问题。

但工具越多，又会出现新的问题。

Anthropic 在 2025 年讨论 MCP 时就指出，当 Agent 同时连接数百甚至数千个工具时，如果把所有工具定义和返回结果全部塞进 Context，会明显增加 Token 消耗和延迟。

于是问题又回到了 Agent Engineering：

不是“有没有工具”。

而是：

什么时候加载哪个工具？什么时候调用？调用结果应该有多少真正进入 Context？

Harness：Agent 在什么环境里工作？

这是我之前研究 Harness 时觉得最有意思的一点。

如果说：

LLM 是大脑，

那么 Harness 更像是：

它工作的房间、桌子、规则和工作制度。

可以粗略写成：

Agent ≈ LLM + Harness

模型负责 Reasoning。

Harness 负责 Execution 和 Control。

文件系统能不能访问？

Terminal 能执行什么？

修改代码以后要不要 Test？

失败以后能不能 Retry？

上下文满了怎么办？

执行多少步以后必须停止？

高风险操作需不需要用户确认？

这些都不应该完全交给模型自由发挥。

Anthropic 在对长时间运行 Agent 的实验中发现，仅仅提高模型能力并不能解决所有问题。为了让 Agent 跨越多个 Context Window 持续工作，他们需要设计任务拆分、进度文件、Git 提交、测试机制以及上下文交接方式。

2026 年 Anthropic 又进一步把 Harness Design 单独拿出来讨论。

这已经说明一个问题：

模型性能只是 Agent 性能的一部分，模型外面的工程结构同样决定 Agent 最终能做到什么。

Evals：Agent 到底做得好不好？

我之前研究 Evals 时，最容易产生的误解是：

不就是给模型打个分吗？

但到了 Agent 这里，Evals 的意义明显升级了。

因为 Agent 有时候最后答案是对的，执行过程却完全错了。

例如：

用户问一个数据库问题。

Agent：

调用错数据库 → 搜索五次 → 重复调用工具 → 浪费大量 Token → 最后碰巧得到了正确答案。

如果只看最终 Answer：

Pass。

但从工程角度看，这是一个非常糟糕的 Agent。

所以 Agent Eval 必须开始评价：

Output + Tool Calls + Trajectory + Context + State

也就是不仅看：

最后答对没有？

还得看：

它是怎么走到这个答案的？

这正是为什么 Anthropic 和 LangChain 现在都开始强调 Agent trajectory、tool-use 和多步骤行为的 evaluation。

Router：下一步到底应该让谁做？

然后就是我研究时间最长的 Router。

以前看 Router，很容易把它理解成：

根据问题选择模型。

简单问题 → 小模型。

复杂问题 → 强模型。

代码问题 → Coding Model。

但如果把 Router 放进 Agent Engineering，事情就开始变得有意思了。

Agent 每走一步，其实都面临一个决策：

下一步应该：

继续推理？
调用 RAG？
搜索网页？
执行代码？
调用工具？
换模型？
使用缓存？
并行执行？
让另一个 Agent 做？
还是交给 Human？

所以 Router 最终很可能不只是一个：

Model Selector

而会不断向：

Decision Engine

演化。

它决定的已经不只是：

“用哪个模型？”

而是：

“下一单位计算资源应该被分配到哪里？”

这也是我认为 Router 真正值得继续研究的地方。

Redis / Cache：为什么所有事情不能重新算一遍？

Agent 一旦开始多步骤执行，成本问题会迅速被放大。

普通 Chatbot 一次可能只调用一次模型。

Agent 为了完成一个任务，可能调用模型十次、二十次甚至更多。

其中大量内容其实是重复的：

系统 Prompt。

工具定义。

用户资料。

RAG 结果。

历史 Context。

相似任务。

重复查询。

这也是为什么我之前研究 Redis 时，越来越觉得 Cache 在 AI 时代的重要性被低估了。

Agent Engineering 不只是研究：

怎么让 Agent 更聪明。

还必须研究：

怎么让 Agent 不要重复思考已经思考过的东西。

Prompt Cache、Semantic Cache、KV Cache、工具结果缓存、RAG 缓存……

它们共同解决的是一个非常现实的问题：

不要为同一份计算重复付钱。

于是 Redis 这种原本看起来非常传统的基础设施，在 Agent 系统里反而重新获得了新的价值。

2026 年 LangChain 对超过 1,300 名工程师、产品经理和企业管理者进行了一次 Agent Engineering 调查。

其中一个非常值得注意的数据是：

57.3% 的受访者已经有 Agent 运行在生产环境。

另有 30.4% 正在开发，并有明确的生产部署计划。

也就是说，对这批受访者而言，“要不要做 Agent”已经不是最核心的问题。

真正的问题开始变成：

怎么把它跑稳定。

而当调查继续问企业最大的障碍是什么时，排名第一的并不是成本。

而是：

Quality。

约 32% 的受访者把质量列为主要障碍之一。

更有意思的是另外一组数据：

89% 的组织已经部署某种 Agent Observability。

但只有：

52.4% 在做 Offline Evals，37.3% 在做 Online Evals。

这个数据非常能说明 Agent Engineering 当前所处的阶段。

大家已经意识到：

必须先看见 Agent 在干什么。

所以 Trace、Logs、Observability 很快普及了。

但下一步：

怎样判断它干得对不对？

Evals 仍然正在快速补课。

我越来越觉得，Agent Engineering 最重要的词不是：

Agent。

而是：

Reliability。

因为传统软件工程面对失败时，从来不会幻想：

“服务器永远不会出问题。”

工程师真正做的是：

Failure
↓
Detection
↓
Retry
↓
Failover
↓
Recovery

Agent Engineering 其实完全一样。

我们没有办法保证模型永远不会判断错误。

真正应该构建的是：

Agent 出错
↓
Observability 发现
↓
Eval / Validator 判断
↓
Retry
↓
换策略
↓
Router 换模型
↓
重新 RAG
↓
必要时 Human Escalation

所以 Agent Engineering 的目标从来不应该是：

制造一个永远不会犯错的 AI。

更现实的目标是：

建立一个即使 AI 犯错，也能够发现、限制、恢复和继续工作的系统。

这也是为什么 Gateway、Router、Evals、Harness、Cache、RAG 最终会走到一起。

它们解决的从来都不是同一个技术问题。

但它们共同解决的是同一个工程问题：

如何把一个不确定的模型，变成一个相对确定的生产系统。

还有一个很值得关注的数据。

LangChain 的 2026 调查显示，超过 四分之三 的受访组织已经在开发或生产中使用多个模型，而不是押注单一模型。

同时，57% 的组织并没有进行 Fine-tuning，而是更多依赖基础模型、Prompt Engineering 和 RAG。

这其实暗示了一个很重要的趋势。

未来企业 AI 的竞争，可能越来越不像：

谁拥有一个最强模型？

而越来越像：

谁能够把模型、数据、工具、缓存、路由、权限、评估和业务流程组织得最好？

模型当然依然重要。

但模型开始越来越像计算机里的 CPU。

CPU 决定计算能力。

可真正决定一台电脑好不好用的，从来不只有 CPU。

操作系统、内存、存储、网络、软件生态、权限、安全机制……

全部重要。

Agent Engineering 做的，其实就是在给 LLM 建这样一套“操作系统”。

如果把过去几年的 AI 工程发展压缩成一条线，我会这样理解：

Prompt Engineering

解决：

怎么让模型回答得更好。

↓

Context Engineering

解决：

模型做决定之前应该看到什么。

↓

Agent Engineering

解决：

怎么让模型可靠地把一件事情真正做完。

所以 Agent Engineering 并不是又一个突然冒出来的新名词。

它更像是过去几年 AI Engineering 自然发展的结果。

当模型只能聊天时，我们研究 Prompt。

当模型开始读取外部资料时，我们研究 RAG。

当 Context 越来越大时，我们研究 Cache。

当模型越来越多时，我们研究 Router。

当 AI 开始调用真实系统时，我们研究 MCP 和 Tools。

当 AI 开始连续行动时，我们需要 Harness。

当系统越来越不可预测时，我们开始研究 Evals 和 Observability。

而当这些东西最终全部组合到一起：

Agent Engineering 出现了。

结语

所以如果现在再问我：

Agent Engineering 到底是什么？

我不会把它简单定义成“开发 Agent 的技术”。

我更愿意说：

Prompt Engineering 是教 AI 怎么回答问题；Agent Engineering，是设计一个世界，让 AI 能在里面工作。

这个世界里需要知识，所以有 RAG。

需要记忆和效率，所以有 Cache。

需要选择，所以有 Router。

需要行动，所以有 Tools 和 MCP。

需要边界，所以有 Harness 和 Guardrails。

需要知道做得怎么样，所以有 Evals 和 Observability。

需要稳定调用，所以还有 Gateway。

而 Agent Engineering 真正做的，就是把这些原本分散的组件组合起来，把：

一个聪明但不稳定的模型

慢慢变成：

一个能够被企业真正使用的生产系统。

某种意义上，这可能才是 Agent 时代真正开始的地方。