上一篇文章发出去之后，有读者问我：你说工程师的价值在迁移，到底迁到哪去了？

这个问题我想了很久。过去半年我的日常工作发生了一个很具体的变化：以前每天打开 IDE 写代码，现在每天打开的是一堆 Spec 文件和 Agent 的执行日志。听起来像是从厨师变成了餐厅经理，但实际体感比这复杂得多。

你以为消失的能力，换了个地方活着

去年有一阵我很焦虑。Redis 集群怎么搭、Kafka 消费组怎么调优、数据库索引怎么设计，这些我花了好几年才摸透的东西，Agent 现在做得比我好。那些曾经让我在团队里有话语权的技术细节，突然变得不值钱了。

但做了几个月 Agent 编排之后，我发现事情没那么简单。

有一次我让三个 Agent 并行处理同一个功能的不同模块。结果上线后出了一个诡异的 bug：两个模块同时写入同一张表，偶发性地互相覆盖数据。排查了半天才反应过来，这就是经典的竞态条件。如果我不懂并发，我甚至不知道该往哪个方向查。

还有一次，Agent 给一个高频查询的表设计了 Schema，字段类型选得没问题，索引也建了，但它把一个需要范围查询的字段放在了联合索引的第二位。上线三天没事，数据量一上来直接慢查询告警。这种判断需要你真正理解数据库的查询优化器是怎么工作的。

传统技术知识没有蒸发，它从台前退到了幕后。以前它是你亲手写代码时的显性技能，现在它是你判断 Agent 输出质量时的隐性基座。我后来想到一个类比：导演不需要自己上台演戏，但不懂表演的人当不了好导演。你得知道什么是好的，才能判断别人做得对不对。

Harness Engineering：给 Agent 搭的那个架构

行业里现在管这件事叫 Harness Engineering。Martin Fowler 写了专题，OpenAI 也出了文章。核心意思是：模型是可替换的组件，真正的产品是包裹模型的那层控制结构。

我自己的实践里，这层控制结构大概分六块：Context 怎么给、验证回路怎么搭、Agent 的状态怎么管、工具怎么编排、什么节点需要人介入、Agent 的生命周期怎么管理。听起来很抽象，举个例子就清楚了。

我有一个项目需要处理用户上传的文件，解析后写入数据库，再触发下游通知。以前的做法是写一个服务，串行处理。现在的做法是拆成三个 Agent：一个管解析，一个管入库，一个管通知。但拆完之后你立刻面对一堆问题：解析失败了怎么回滚？入库到一半 Agent 挂了，状态怎么恢复？通知发重了怎么办？

这些问题的本质和十年前搭微服务架构时遇到的一模一样。只是对象从"服务"变成了"Agent"。你设计的东西从 API Gateway 变成了 Context 注入策略，从消息队列变成了 Agent 之间的状态传递协议，从熔断器变成了 Agent 执行失败时的降级方案。

2026 年我观察到一个现象：AI 产品做得好的公司，往往不是有独家模型的那些。它们的共同特点是 Harness 工程做得极其成熟。模型换了一代又一代，它们的控制层稳如磐石。对它们来说，模型就像数据库引擎，重要但可替换；Harness 才是业务逻辑，才是护城河。

价值公式悄悄改写了

这个变化带来一个后果：衡量工程师价值的公式变了。

以前的公式大概是：知识量 x 执行力。你记住的 API 越多、写代码越快，你就越值钱。面试考算法、考数据结构、考八股文，底层逻辑就是在测你的知识量。

现在这个公式正在被改写成：理解深度 x 问题定义能力 x 驾驭能力。你对一个领域理解多深，决定了你能不能发现 Agent 犯的隐蔽错误。你定义问题的能力，决定了 Agent 的工作质量上限。你驾驭 Agent 工作流的能力，决定了整体的交付效率。

但教育体系和人才评估体系还没反应过来。我前阵子看了几家大厂的面试题，还在考链表反转、红黑树、TCP 三次握手。这些恰恰是 Agent 最擅长的东西。你在筛选的是"谁的记忆力更好"，但你真正需要的是"谁能在模糊的商业需求里提取出一个可执行的命题"。

这两种能力几乎没有相关性。

Context Engineering：最重要的技能，偏偏不是技术

行业里很多人把 Context Engineering 称为 2026 年 AI 开发者最重要的技能。我同意这个判断，但我想补充一点：它本质上是一种认知能力，不是技术能力。

我写过 300 多个 Spec。写到第 200 个的时候我突然意识到，真正有用的那些 Spec 有一个共同点：它们写的都是"为什么"，而不是"怎么做"。为什么这个数据必须走服务端、为什么这个缓存策略要用 LRU 而不是 FIFO、为什么这个接口必须幂等。这些"为什么"就是 Context 的核心。

你不理解业务，你就不知道该给 Agent 什么 Context。你不理解系统的运行机制，你就不知道该设什么约束条件。一个对业务一知半解的人写出来的 Spec，和一个深入理解业务的人写出来的，Agent 执行的结果天差地别。

这意味着 Context Engineering 其实是在考验你对整个问题域的理解深度。工具和格式都是表面的，底层是你到底懂不懂这件事。

那最后一层会不会也被替代？

如果 Agent 持续进化，我现在做的这些"判断"和"定义"，会不会也被替代？上一篇圆桌讨论里我们聊过这个问题，当时的共识是：至少目前，"从混沌现实中抽取可执行命题"这件事还是人的活，因为它需要意图，而 Agent 没有意图。

半年过去了，我对这个判断稍微松动了一点。Agent 在结构化问题上的定义能力已经比很多初级工程师强了。但在真正模糊的、涉及商业判断和价值取舍的领域，它确实还差得远。

我现在的策略是不去预测那个终极答案，而是持续把自己推到 Agent 做不了的那层去。上一个阶段是写代码，我退到了定义架构。这个阶段是定义架构，我正在退到定义问题本身。如果有一天"定义问题"也被替代了，那一定又有新的一层浮现出来。

从我自己的四个阶段走过来，有一件事变得越来越清楚：每一次退后都不是贬值，而是被迫去面对更本质的问题。以前写代码的时候可以不想"为什么要做这个功能"，现在不行了。以前做架构的时候可以不想"这个产品解决的到底是什么问题"，现在也不行了。

Agent 在替代你做事的同时，也在逼你想清楚你到底要做什么事。这个过程不舒服，但回头看，每一步逼出来的思考都是真正值钱的东西。

别等着想清楚了再动手。一边做一边想，是现在唯一可行的策略。