Agent工程师的核心能力：在不确定性上构建确定性

今天聊一个我觉得比任何具体框架都重要的问题：Agent 工程师的核心能力到底是什么。

这个问题之所以重要，是因为每次我发一个新的 Agent 概念的视频，评论区、粉丝群里一定会有人说这句话："学这些很快过时了。"

他们不是没有道理，背后有两个原因。

两个原因

第一个原因：框架迭代太快，学了等于白学。

LangChain 从 0.1 到 0.3，接口全改了；AutoGen 的多 Agent 写法换了好几轮；LlamaIndex 的 Agent 模块重构了两三次。如果你学的是怎么调某个框架的某个类、某个方法，那确实半年就过期——你今天背熟的 API 签名，下个版本可能连类名都不存在了。

第二个原因更加重要：模型能力的进化本身就在不断吞噬工程代码。

• 模型上下文窗口只有 4000 个 token 的时候，你必须做分块检索、拼接，写一整套 RAG 流水线；窗口变成 128K 甚至更长之后，很多场景下这套流水线确实不需要了。
• 模型不会用工具的时候，你得写复杂的提示词教它输出特定格式，然后用正则去解析；模型原生支持 tool use 之后，这些代码可以直接删掉。
• 模型推理能力变强之后，很多以前需要 Chain of Thought 手动引导的场景，现在一个 prompt 就能搞定。

所以有人下结论：Agent 开发就是给模型打补丁，模型越强补丁越少，最后工程师就没活干了。

这两个原因都指向同一个焦虑：我现在学的东西，保质期到底有多长？

我的回答是：取决于你学的到底是什么。

两类工程

因为 Agent 开发里有两类完全不同的工程。

补偿性工程

它的本质是用外部代码弥补模型能力的不足。窗口太小，你就做分块检索；模型不会调工具，你就写输出解析器；模型容易跑偏，你就手写 Chain of Thought 模板一步步引导它。

这类工程确实会过时。模型能力一提升，对应的代码就可以直接删掉。说它保质期短，完全正确。

系统性工程

它解决的不是"模型不够强"的问题，而是任何智能体在真实环境中工作都必须面对的问题。不管模型强到什么程度，这类工程不会消失。

我们回顾一下：从 2023 年初的 ReAct 模式，到 2023 年底的 Plan and Execute，再到 2024 年的 Multi-Agent，2025 年的 Context Engineering，再到现在的 Harness Engineering——名词换了五六轮，但每一次所谓的范式切换，解决的核心问题从来没变过。

今天我就把这些不变的东西讲清楚。

四项核心能力

先说结论：Agent 工程师的核心能力就四件事——上下文管理、控制流设计、错误恢复、反馈回路。

无论你是什么背景的工程师，你一定觉得这四个词似曾相识。没错：

• 上下文管理 = 状态管理
• 控制流设计 = 流程编排
• 错误恢复 = 异常处理
• 反馈回路 = 监控告警

Agent 开发没有发明新的工程学科，它站在传统软件工程的地基上。但它多了一层全新的挑战：你的核心引擎不再是你亲手写出来的确定性逻辑，而是一个概率性的黑核（模型）。

就这一个差异，把同样的四件事变成了完全不同的工程问题。

前提：Agent = Model + Harness

在展开之前，先快速对齐一个前提。现在行业逐渐形成了一个共识：

Agent = Model + Harness

• 模型负责智能推理、决策
• Harness 负责模型之外的一切：工具、知识、上下文管理、权限边界

模型是引擎，Harness 是方向盘和刹车。模型做决策，Harness 提供执行环境。模型负责思考，Harness 负责让思考落地。

而我们 Agent 工程师的工作就是造车。发动机不是我们造的，那是 Anthropic、OpenAI、Google 的事。我们造的是底盘、方向盘、刹车系统、仪表盘和安全气囊。

好，前提讲清楚了，我们来逐一拆解这四项核心能力。

---

第一项：上下文管理

你写后端的时候，状态管理是什么？Session 里存用户信息，Redis 里存缓存，数据库里存业务数据。你操心的是数据存在哪、什么时候读、什么时候写、一致性怎么保证。但你从来不需要担心一件事：你存进去的数据不会影响你的业务逻辑正不正确。 你的 Service 层不会因为 Redis 里多了一条脏数据就开始胡言乱语。逻辑是你写死的，数据是数据，逻辑是逻辑，二者泾渭分明。

Agent 开发里，这个前提不成立了。

Agent 没有你手写的 if-else，它的全部逻辑都是模型在推理时基于上下文生成的。你给它什么信息、给的顺序、给的措辞、信息量的多少，直接决定它的推理质量和行为方向。

换句话说：上下文不是数据，上下文就是程序本身。

所以 Agent 开发里的上下文管理，至少要解决三个层次的问题：

层次一：上下文隔离

当你把一个大任务拆成多个子任务时，每个子任务应该有自己独立的上下文。如果你把主任务的所有历史消息带进子任务，模型会被无关信息干扰，推理质量下降。

子任务的独立上下文本质上是一道防火墙，防止一个子任务的噪声污染另一个子任务的推理。这也是为什么 Claude Code 的子代理模式、OpenAI Codex 的沙箱执行都在做同一件事。

层次二：按需注入

不要把所有知识一股脑塞进 System Prompt。模型需要什么信息，在它需要的时候再给它。上下文窗口是稀缺资源，塞太多无关信息等于往模型的工作台上堆满杂物，它反而找不到真正有用的东西。

这和 OpenAI 把 AGENTS.md 控制在 100 行、Anthropic 做 Skill 渐进式加载是同一个道理。

层次三：上下文压缩

Agent 持续运行，上下文会不断膨胀，但模型的推理能力会随着上下文膨胀而退化。你的数据库不会因为存的数据太多而算错 SQL，但模型会。所以你需要压缩策略——在保留关键信息的前提下，定期为上下文瘦身。

从 2023 年 ReAct 时代手写 prompt 模板安排信息顺序，到 2025 年正式提出 Context Engineering，行业花了三年才给这件事正式命名。但底下的事情一直是同一件事：你管理的不是数据的正确性，你管理的是模型在每一个决策瞬间，能不能看到正确的、充分的、不过载的信息。

---

第二项：控制流设计

你写一个 Service 方法，每一步做什么、下一步走哪个分支，全由你的代码决定。

Agent 开发里，下一步做什么不是你决定的，是模型决定的。所有 Agent 框架的核心都是同一个循环：调模型 → 模型说要调工具就调工具 → 把结果喂回去继续循环 → 模型说停就停。循环本身没有任何业务逻辑，模型自己决定什么时候调用工具、调用哪个工具、什么时候结束。

但让模型自己决定，不等于你什么都不用设计。 恰恰相反，你需要设计更精巧的控制结构。

比如计划机制。 一个没有计划的 Agent 会漫无目的地漂移。你不写死流程，但你给模型一个"先列计划再执行"的工具，引导它在行动前先想清楚步骤。实测表明，加了计划机制的 Agent 任务完成率几乎翻倍。

比如任务依赖图。 你不写死执行顺序，但你提供一个结构，让模型自己把大目标拆成有依赖关系的小任务，按依赖关系逐步推进——完成一个才解锁下一个。

比如自主认领机制。 在多 Agent 协作的场景里，你不指派任务，而是设计一个看板——Agent 自己扫描、自己认领、自己执行。

看到规律了吗？

传统控制流是你写死的 A → B → C。Agent 的控制流是你设计一个棋盘，模型在棋盘内自主决策。 你不控制每一步怎么走，你控制它能走的范围。

这需要一种完全不同的设计思维——从命令式转向声明式 + 约束式。约束解空间，反而提高了产出。

---

第三项：错误恢复

传统后端的异常处理——try-catch、事务回滚、重试、降级、熔断——它有一个隐含的前提假设：逻辑是对的，只是执行可能失败。 网络超时、数据库挂了、下游返回 500 状态码，这些都是环境故障，不是逻辑错误。你的代码本身不会犯错。

Agent 开发里，这个假设也不成立了。

模型会误解意图、选错工具、传错参数，甚至产生幻觉——声称已经完成了实际没完成的操作。这不是 bug，不是异常，这是概率系统的本性。犯错是它工作方式的一部分。

所以 Agent 的错误恢复要处理两层问题：

• 传统的环境故障：API 超时、文件不存在
• 全新的智能故障：模型推理本身出错

怎么应对智能故障？核心原则是在架构层面隔离错误，不让它级联传播。 子任务用独立上下文执行，失败了，它的错误推理轨迹不会污染主任务。主任务只拿到最终结果，然后决定下一步。这和微服务架构里的故障隔离原理完全一致。

多 Agent 协作时，每个 Agent 在独立的工作目录里执行。你不能假设 Agent 每次都改对文件，一个 Agent 的错误不能波及其他 Agent 的工作空间。

OpenAI Codex 团队分享过一个经验，我觉得特别精辟：

"当 Agent 出错的时候，解决方案几乎从来不是让它再试一次，而是去思考模型缺了什么能力或者什么信息，然后把那个东西补上。"

这句话值得反复品味。

传统开发里，retry 是一个合理的策略，因为错误来自环境波动，重试可能就好了。但 Agent 的智能故障不是随机波动，是结构性缺陷——模型缺了关键信息，你让它试 100 次，它 100 次都会犯同样的错。正确的做法是找到那个缺失的信息或能力，把它补进 Harness 里。

---

第四项：反馈回路

传统后端的监控告警，你监控的是系统运行状态——QPS、延迟、错误率。这些数据是给你看的，给人类工程师看的，你看到异常后人工介入处理。

Agent 开发里，反馈不是给人看的。反馈是给模型看的。

最简单的例子：计划跟踪。 Agent 执行过程中，系统不断把"你的计划列表里还有哪些没做完"注入到它的上下文里，防止它跑偏。这不是给人看的 dashboard，这是给模型看的实时仪表盘。

再比如后台任务通知。 耗时操作放到后台异步执行，执行完毕后结果通过通知机制注入 Agent 的上下文，Agent 据此决定下一步行动。

还有自验证循环——中间件在 Agent 准备退出时拦截它，强制执行一轮验证推理。三明治策略也是反馈回路的体现：规划阶段用最高推理强度理解问题，执行阶段降低强度保证速度，验证阶段再拉回最高强度捕获错误。

反馈回路的本质是：让执行结果实时回流到模型的上下文中，驱动它自我评估和修正。 不等人来看，不等人来修，系统自己形成闭环。

---

回应质疑

好，四项核心能力讲完了。现在回应一个更深层的质疑。

有人会说：你讲的这些，迟早会被模型本身内化掉。

更强的模型确实在不断吞噬曾经属于 Harness 的功能。但这个论点有一个根本性的盲区。

这里有一个类比可以说清楚：

• CPU 的性能在过去几十年提升了几百万倍，但我们并没有因此不再需要操作系统。
• 数据库引擎越来越强大，但我们并没有因此不再需要数据库设计。
• 编译器的优化越来越智能，但我们并没有因此不再需要软件架构。

为什么？因为每一次底层能力的提升，都会淘汰一批补偿性的工程实践，同时让系统性的工程实践变得更重要，而不是更不重要。

底层能力越强，你能用它构建的系统就越复杂；而越复杂的系统，越需要精心的工程设计。

Agent 也一样。模型越强，你能让它做的事就越多、越复杂；而越复杂的任务，越需要精细的上下文管理、控制流设计、错误恢复和反馈回路。

拿上下文管理举一个具体的例子：就算模型的上下文窗口变成无限大，你仍然需要上下文管理。因为问题从来不是"装不装得下"，而是**"该不该装进去"**。窗口从 4K 变成 128K，你的工程问题不是消失了，是从"怎么把信息塞进去"变成了"怎么在海量可用信息中筛选出此刻真正相关的那一小部分"。

错误恢复也一样。你的模型可以聪明到从不写错代码，但它调用的第三方 API 照样会返回 500。Agent 操作的是真实环境，真实环境的不确定性不会因为模型变强而消失。故障隔离、回滚机制、降级策略——这些不是因为模型笨才需要的，是因为物理世界不可控才需要的。

控制流和反馈回路就更不用说了。在生产环境中，你需要可审计性、可中断性、可恢复性。模型再强，它也不知道它刚刚写入的文件有没有通过 CI 测试。这些信息必须从外部世界采集回来，注入模型的上下文，才能驱动下一步决策。这不是在补偿模型弱点，这是在给模型提供它原理上无法自行获取的信息。

---

最后总结

有人说 Agent 开发就是换皮 CRUD，和以前写 Spring Boot 调包没区别。对，也不对。

日常操作确实像 CRUD——注册工具、读取上下文、更新状态、压缩历史。但本质区别在于：你的核心引擎从确定性逻辑变成了概率性黑核。 表面相似，底层逻辑完全不同。能不能看穿这一层，决定了你是 Agent 调包侠还是 Harness 工程师。

Agent 工程师的核心能力，是在不确定性之上构建确定性。

• 你的核心引擎是概率性的，它会犯错、会幻觉、会跑偏。
• 你的工程任务是在它周围建造一个系统，让最终交付的结果是可靠的、可预期的、可恢复的。

上下文管理——让模型在每个决策瞬间看到正确的信息。 控制流设计——给模型一个结构化的棋盘，让它自主推进。 错误恢复——假设模型一定会犯错，在架构层面隔离和修复。 反馈回路——让执行结果实时回流，驱动模型自我修正。

这四件事，从 ReAct 到 Harness Engineering，从未改变。

框架会过时，API 会迭代，但如何让一个概率系统可靠地完成工作——这个问题不会过时。

把时间花在不变的东西上，这是我能给你的最好的建议。