Coding Agent 时代的 AI 工程能力模型：从代码实现到 Intent、Runtime 与 Eval 闭环

吴恩达的《The AI Engineering Skills Map》列出了四项 AI Engineering skills。本文不做原文翻译，而是从工程系统角度重新组织这四项能力：当明确规格的实现逐渐被 Coding Agent 商品化，工程师的核心价值正在迁移到定义 Intent、设计 Spec、组织 Runtime，以及用 Eval 验证一次构建。

关键词：AI Engineering、Coding Agent、Intent、Spec、Agent Runtime、Harness、Eval、多 Agent 协作

1. 一个越来越常见的开发场景

给 AI 一句需求，让 Coding Agent 连续开发十几个小时。回来后，系统页面已经可以使用，主要功能也基本成形。

如果只看代码产出速度，这种效率在几年前几乎不可想象。但真正进入使用阶段，另一组问题很快出现：Bug 与交互缺陷很多；需求在多轮执行中发生漂移；多个 Agent 没有共享稳定状态；已经讨论过的结论无法持续命中缓存；每次修正更像给当前会话打补丁，而不是更新系统规格。

这不是一个简单的“模型还不够强”问题。它暴露的是 Coding Agent 时代更基础的工程矛盾：

代码生成能力增长得很快，但定义、组织和验证一次构建的能力没有同步系统化。

当实现明确规格越来越便宜，工程瓶颈就会向规格的上游与验收的下游迁移。工程师并没有从系统中消失，而是需要从“代码生产者”进一步成为“构建系统的设计者”。

2. 吴恩达提出的四项 AI Engineering skills

北京时间 2026 年 8 月 15 日 00:29，吴恩达发布 X Article《The AI Engineering Skills Map》。DeepLearning.AI 分析了超过 10,000 条招聘信息，并结合数十次 AI 专家、招聘经理和招聘人员的结构化访谈、问卷及线上资料，归纳出四项能力：

1. Building and deploying AI applications：构建和部署 AI 应用；
2. Software engineering fundamentals：软件工程基础；
3. Using coding agents：使用 Coding Agent；
4. Shaping the build：塑造要构建的东西。

原文还强调 continuous learning，并明确区分广义的 AI Engineering skills 与狭义的“AI Engineer”职位。换言之，这不是只为某个岗位准备的资格清单，而是 AI 进入软件开发之后，开发者普遍需要重新组合的一组能力。

但如果把四项能力仅仅理解为四个学习模块，会遗漏它们之间最重要的关系：这四项能力共同组成了一次构建的生命周期。

3. 能力迁移：从写代码到塑造构建

传统软件开发当然也需要需求、设计、测试和反馈。Coding Agent 带来的变化，不是发明了这些环节，而是显著改变了它们的相对稀缺度。

工程环节	传统开发中的常见重心	Coding Agent 时代的新问题	更稀缺的能力
问题定义	人工沟通并形成需求文档	一句自然语言很容易直接触发大量实现	澄清 Intent、边界与成功标准
系统设计	架构师与开发者共同拆分	Agent 能快速生成局部方案，但未必保持全局一致	状态建模、依赖管理、工程权衡
代码实现	人力投入最大的阶段之一	明确规格的实现速度快速提升	任务切分、上下文供给、Agent 调度
测试验收	验证代码是否符合需求	“任务执行成功”容易被误当成“产品可用”	Eval、Trace、回归验证、用户反馈
迭代维护	修改代码并同步文档	对话补丁无法稳定继承，多个 Agent 口径漂移	规格版本化、持续记忆、决策追踪

因此，“实现能力商品化”并不代表代码质量自动提升。它只意味着单位时间内可以生成更多代码、尝试更多方案。没有更强的规格与验证系统，产出速度也可能放大返工、冲突和技术债。

4. 我们的重组：把四项能力连接成闭环

4.1 Shaping the Build：先确定要构建什么

Intent 描述为什么构建、为谁构建以及希望改变什么。Spec 则把意图进一步变成可执行约束，包括功能行为、交互流程、数据边界、异常处理、非功能需求和验收标准。

一句需求可以启动生成，但不能自动成为完整规格。如果边界没有被显式表达，Coding Agent 通常会用自己的默认假设填补空白。实现越快，这些隐含假设扩散得也越快。

4.2 Software Engineering Fundamentals：把规格转成系统边界

Agent 可以生成代码，却不能替团队承担全部架构责任。状态放在哪里、模块如何拆分、接口怎样稳定、失败如何恢复、哪些路径必须确定性执行，这些仍依赖软件工程判断。

基本功在 Agent 时代甚至更重要，因为工程师需要审查的不再只是自己写出的方案，还包括大量高速生成的候选方案。没有扎实的工程判断，就无法区分“看起来能运行”和“可以进入长期维护”的实现。

4.3 Coding Agent / Runtime / Harness：组织实现过程

真正的 Agent 工程环境不只是一个聊天框。它至少需要管理：

• 工具、权限与执行隔离；
• 上下文装载与缓存策略；
• 任务依赖与并发调度；
• 检查点、重试与失败恢复；
• 多 Agent 的共享状态与决策记录；
• 执行过程的 Trace 与成本观测。

模型能力决定 Agent 理论上能完成什么，Runtime 与 Harness 决定这些能力能否跨越多个小时、多个任务和多次修订，稳定地形成一个整体。

4.4 AI Application / Eval / Feedback：证明结果满足意图

“代码已生成”“测试进程退出码为 0”“页面可以打开”，都不能单独证明构建成功。最终系统还需要回答：用户任务是否真正完成？交互是否合理？模型输出是否稳定？异常路径是否可控？新修改是否破坏旧能力？

这些问题需要自动化测试、模型 Eval、运行 Trace、人工审查和真实用户反馈共同回答。验证结果还必须回流到 Intent 与 Spec，形成下一轮迭代输入。

5. 真实案例：为什么两个 Agent 没有变成一个团队

我们曾希望 Fable5 与 ChatGPT 5.6 在同一个聊天室里围绕需求讨论、互相审查并达成一致。实际运行中，两者却完全割裂。

一个 Agent 的判断没有稳定进入另一个 Agent 的上下文；推导过的信息没有形成可复用缓存；需求修正停留在局部会话；后续执行也没有可靠继承前一轮状态。系统表面上具备多 Agent，实质上只是多个独立执行者。

这个失败案例可以拆成五类工程缺口：

缺口	表现	需要的机制
共享状态缺失	各 Agent 持有不同需求版本	单一有效 Spec、状态存储、版本控制
记忆不可持续	上一轮结论无法可靠继承	长期记忆、决策日志、上下文检索
缓存不可复用	相同问题反复推导	稳定缓存键、来源追踪、失效策略
协作协议缺失	没有明确的提案、审查与裁决过程	角色协议、审批门、冲突解决规则
验收口径分裂	每个 Agent 用自己的标准判断完成	共享 Eval、统一验收条件、回归基线

这里最关键的判断是：

多 Agent 不会因为处在同一聊天室就自动形成协作。协作需要共享对象、状态协议、控制循环和统一的完成定义。

6. Intent 与 Spec 应该成为 Runtime 的一等对象

在我们接触到的许多 Agent Runtime 中，Task、Message、Tool Call、Artifact 和 Run 已经是核心对象，“为什么构建”“当前有效需求是什么”“怎样算完成”却仍留在自然语言聊天记录中。

这会导致一个结构性问题：执行过程可以被调度和追踪，构建意图却无法被稳定查询、版本化或验证。

一种可能的演进方向，是在 Runtime 中引入类似 BuildSpec 的一等对象：

build_spec:
  id: build-spec-042
  version: 7
  intent:
    user_problem: "..."
    desired_outcome: "..."
  constraints:
    must: []
    must_not: []
  acceptance_criteria:
    - id: AC-01
      evaluator: automated_test
    - id: AC-02
      evaluator: human_review
  task_graph: []
  decision_refs: []
  artifact_refs: []
  eval_refs: []
  supersedes: build-spec-041

这不是建议所有 Runtime 都采用同一个 Schema，而是强调 Spec 应具备一等对象的基本性质：

• 可版本化：需求变化有明确差异与来源；
• 可分解：目标、约束、任务和依赖可以建立结构化关系；
• 可共享：多个 Agent 使用同一份有效状态；
• 可追踪：代码、测试、决策和结果可以回指规格；
• 可验证：验收条件能够直接连接 Test 与 Eval；
• 可回流：线上缺陷与反馈能够触发规格更新。

一旦如此，Shaping the Build 就不再只是编码前的产品分析，而会成为贯穿运行时的持续控制过程。Spec 也不再是写完后逐渐失效的文档，而是人、Agent、代码与 Eval 共同遵守的构建协议。

7. “会用 Coding Agent”正在成为独立工程方向

吴恩达把 Using coding agents 单列为一项能力，意味着“会用”不能再被简化为写 Prompt 或熟悉某个产品。

围绕 Coding Agent，已经可以看到一组相互耦合的工程子问题：

• Context Engineering：选择、压缩、排序并注入正确上下文；
• Loop Engineering：设计计划、执行、评估和修正循环；
• Harness Engineering：管理工具、权限、隔离、检查点与恢复；
• Graph Engineering：表达任务依赖、知识关系与多 Agent 协作；
• Agent Runtime：管理状态、记忆、调度、观测与长期运行；
• Eval Engineering：把质量、正确性和业务目标转成可重复验证的标准。

这些方向研究的不只是软件系统本身，还包括“软件如何被 Agent 持续构建”。它们不会取代软件工程，而是在 Intent、执行过程和结果验证三个方向扩展软件工程的边界。

8. 一份可以落地的 Agent 构建检查清单

在把长期任务交给 Coding Agent 前，可以先检查以下问题。

Intent 与 Spec

• 用户问题、目标结果和非目标是否明确？
• 关键约束是否写入统一规格，而不是散落在聊天记录中？
• 每项验收条件是否有对应 Test、Eval 或人工审批？

Runtime 与 Harness

• Agent 是否只能访问完成任务所需的工具与权限？
• 长任务是否有检查点、重试、暂停和失败恢复机制？
• 多 Agent 是否共享同一版本的状态、决策与工件索引？
• 缓存是否有稳定键、来源记录与失效条件？

Eval 与反馈

• 是否区分“任务执行成功”和“用户目标达成”？
• 是否覆盖正常路径、异常路径与回归场景？
• 用户反馈能否回指具体 Spec，并进入下一轮构建？

如果这些问题没有答案，增加 Agent 数量或延长自主运行时间，未必能提高交付质量，只可能更快放大系统中的不一致。

9. 这张 Skills Map 的价值与局限

这张地图的价值是提供了一组共同语言，并把 Shaping the Build、软件工程、Coding Agent 和 AI 应用构建放在同一个视野中。它也提醒开发者：AI Engineering skills 的适用范围大于狭义的“AI Engineer”职位。

但它目前仍是高层框架，不能直接当作成熟岗位标准。原文尚未公开完整数据集、岗位样本的地区与行业分布、聚类方法，以及各项能力的技能等级标准。我们无法据此判断不同岗位的能力权重，也无法准确描述初级、中级和高级工程师的分级要求。

Building and deploying AI applications 的范围同样很宽。调用模型 API、构建 RAG、训练模型、设计 Eval、生产部署与线上监控，对应的是差异很大的工程能力。如果后续没有更细的分层，这一项容易成为包罗万象的容器。

吴恩达在补充回复中说明，这是 DeepLearning.AI 的长期计划，远不止一门课程。因此，更合适的理解是：当前地图是一项研究与课程议程的起点，而不是最终答案。

10. 结论：工程师正在设计“构建本身”

Coding Agent 让明确规格的实现能力快速商品化，但它不会自动完成问题定义、架构权衡、状态组织和结果验证。

未来优秀工程师的代表性能力，可能不再只是“写了多少代码”，还包括：

1. 把模糊意图变成可执行、可验证的 Spec；
2. 让多个 Agent 在共享状态和统一协议下协作；
3. 设计能够暴露错误、保存决策并持续收敛的 Runtime；
4. 用 Test、Eval、Trace 和用户反馈证明系统解决了真实问题。

代码仍然是工程的材料，但定义、组织和验证一次构建，正在成为更稀缺的工程能力。

参考来源

• 吴恩达发布的 X 帖子
• X Article：《The AI Engineering Skills Map》
• 吴恩达关于 DeepLearning.AI 长期计划的补充回复