Agent 时代软件构建革命：黄东旭百亿 Token 实践后的深度思考

黄东旭（TiDB CTO）在高强度 Agent 实战后提出了一个核心判断：代码作为人类思考媒介的地位正在下降，而定义目标、提供上下文、收紧约束的能力正在成为新的稀缺品。本文整理了他的观点链条和工程方法，不涉及"AI 会不会替代程序员"的泛泛讨论。

§1 先给结论

8 个判断，先放在前面，后文逐条展开：

1. “Coding 已死"指的是代码作为人类主要思考媒介的地位在下降，编程知识本身没有失效。
2. Agent 时代最稀缺的能力，是把 Goal（目标）、Context（上下文）、Constraints（约束）讲清楚，写代码只是其中一环。
3. 多 Agent 协作不自动提升质量；缺高质量 Spec（规格说明）和验收标准，系统只会更快跑偏。
4. **趋势：**软件形态会从固定界面走向意图驱动，UI 退居辅助层但不会消失。
5. **趋势：**产业机会向两端集中：一端贴近人的意图与体验，另一端贴近机器执行与基础设施。
6. **趋势：**Skill（技能）大概率是过渡抽象，下一代交付物更像可组合、可调试、能蒸馏专家知识的 Stack。
7. 程序员不会消失，但会快速分化：低杠杆实现劳动贬值，对结果、验证和边界负责的工程师升值。
8. **趋势：**长期看，生成能力会商品化，验证与治理能力会变成稀缺基础设施。

§2 推理链怎么走

§1 的 8 条判断不是并列陈列，而是一条链：先说代码作为思考媒介的地位在松动（第 1、2 条），再讲为什么补 Spec、收紧约束比堆 Agent 更关键（第 3 条），接着推演软件形态、产业格局和 Skill 的局限（第 4-6 条），回到人的位置——程序员能力如何分化（第 7 条），最后落到"验证与治理会变稀缺"这个大判断（第 8 条）。正文从 §3 起先交代信息来源边界，再逐条展开。

§3 阅读边界

本文内容分为三类，读的时候留意区分：

• 自述事实：个人或团队实践中的经验样本，未必能外推到所有团队。
• 方法判断：对"怎样更有效"的工程结论，值得试，但需在本团队验证。
• 趋势推演：对产业结构和软件形态的预测，重点看方向，别当时间表。文中所有标注"趋势：“的观点均属此类。

黄东旭的原始分享（演讲视频、公众号文章等）暂未在公开渠道统一归档，可关注其微信公众号及 TiDB/PingCAP 官方渠道获取原始材料。

§4 背景：一个 CTO 与他的 Agent Team

4.1 为什么这个案例值得看

黄东旭是 TiDB 联合创始人兼 CTO，工程师出身，长期在一线。这轮分享稀有之处在于：它围绕复杂基础软件展开，谈的是长程任务、协作方式和约束体系，把 Agent 当作一个需要被组织、被管理、被约束的"软件生产系统”，而不是效率插件。

4.2 这次实践样本说明了什么

按其自述，过去几个月里，他主要通过 AI Coding Agent 推进一个体量很大的基础软件项目，项目已经进入生产环境并有客户使用。他提到自己在这个过程中消耗了上百亿 Token。

这两个信息分别指向两个判断：

1. Agent 已经开始具备处理长程复杂任务的可能性，不再只是补全代码的小工具。
2. 想把 Agent 用到真正复杂的软件交付上，成本、组织方式和约束体系都不能按"聊天机器人"思路来理解。

4.3 Token 不是指标，交付才是指标

黄东旭说得直白：别把 Token 消耗当指标，要看你最终交付了什么——它能不能用？它有没有让某类复杂任务的完成方式真的变了？

很多团队现在的误区：

1. 把调用量当成成果。
2. 把多 Agent 并发当成能力。
3. 把"生成了很多代码"当成交付。

没有可运行的结果、没有可验收的标准、没有可回滚的路径，Token 烧得再多也只是成本，说明不了生产力。

§5 如何理解"Coding 已死”

5.1 它说的不是"编程没用了"

过去，代码同时承担两种角色：

黄东旭想强调的是，在 Agent 深度参与之后，第二层角色正在被削弱。

人类越来越少通过"亲手写每一行代码"来完成思考，更多通过定义目标、边界、验收和上下文来驱动系统产出代码。

编程知识没有失效，但代码作为思考媒介的垄断地位在松动。

5.2 软件生产的推理链

他的核心推理可以压缩成下面这段：

复杂软件任务 = 大量局部问题的组织与拼接
如果模型与 Agent 已经能稳定完成足够多的局部问题
那么软件生产的总体上限，就会被重新抬高

“复杂工程只能靠人工一点点啃"的旧前提开始松动，但这不代表所有复杂工程都已经被解决。

5.3 人类工作的重心因此转移

在这种框架下，人类的主要职责转向三件事：

1. 定义 Goal，也就是到底要解决什么问题。
2. 提供足够的 Context，也就是 Agent 完成任务所需的背景、规则和历史。
3. 收紧 Constraints，也就是给系统建立可执行、可验证、可回滚的边界。

过去软件工程的重心是"怎样把代码写出来”。到了 Agent 时代，重心移了——变成"怎样把目标讲清楚、把背景材料备齐、把缰绳拉紧不跑偏"。这三件事，全都不是写代码本身，而是写代码之前的准备工作。

§6 Goal / Context / Constraints：Agent 软件生产的三维框架

黄东旭提出的 Goal / Context / Constraints 这组框架，能把很多零散讨论重新归位。它不是什么高深理论，就是帮你把"为什么 Agent 表现不好"这件事，从模糊抱怨变成可诊断的问题。

6.1 三维分工一览

Goal 决定方向——到底要做什么，人类负责明确需求、非目标和验收标准。Context 决定 Agent 能不能做对——提供代码背景、业务知识和历史决策。Constraints 决定系统有没有资格进生产——建立边界、测试、权限和回滚机制。

最常见的失败模式都能对号入座。Goal 没写清楚，Agent 会沿错误方向一路狂奔，越勤奋越离谱。Context 给得不准，模型会拿训练数据里的旧知识硬补，看起来置信度很高，实际上是在编造前提。Constraints 立不住更隐蔽——Agent 可能在局部测试里全绿，却把灰度开关默认值写反，把一个"看起来正确"的版本送进生产环境。三种失败看上去都像模型问题，根因都在上游三维没立住。

6.2 Goal：为什么最难的反而是"讲清楚自己要什么"

黄东旭提到，人类经常并不知道自己真正要什么。放到 Agent 系统里，这个判断很具体——Agent 的执行能力一旦增强，错误目标会被更快放大。

一个合格的 Goal，至少要回答 4 个问题：

1. 成功是什么。
2. 不做什么。
3. 如何验收。
4. 如果做偏了，谁来裁决。

很多产品试图降低 Goal 表达成本，但降低门槛不解决"用户自己也没想清楚"的问题。

6.3 Context：喂得准比喂得多重要

真正有价值的 Context，通常有 3 个特征：

1. 与当前任务强相关，背景不是越多越好。
2. 能解释历史选择，而不只是给现状代码。
3. 能帮助模型做取舍，而不只是堆素材。

黄东旭提到的 Memory、RAG、Harness Engineering，从工程上看都在解决同一件事：如何让 Agent 拿到正确的前提。Context 是最容易被误做成"堆料工程"的方向——把所有相关文档塞进去，反而会稀释信号。

6.4 Constraints：决定能不能上线的维度

Goal 决定方向，Context 决定 Agent 能不能理解对，而 Constraints 决定系统有没有资格接近生产环境。

常见约束包括：

1. Sandbox，限制破坏范围。
2. 测试环境，验证行为而不是只看表述。
3. CI/CD 和 Lint，让产出先过最低质量门槛。
4. 权限和审批流，避免 Agent 在高风险路径上自动放权。

Constraints 最容易被忽视，却也最决定能不能上线。很多团队表面上在研究 Agent，实际上最缺的不是模型能力，而是约束体系。没有约束，任何"看起来聪明"的系统都很难稳定进入真实业务流程。

§7 人机协同：为什么 Spec 比"多开几个 Agent"更重要

7.1 从黑盒自治到"人在环中"

黄东旭一开始尝试的是比较激进的方式：尽量不干预，让 Agent 自己讨论、自己开发、自己消耗 Token，希望通过更大规模换来更高质量。

实践结果并不理想。长程复杂任务不是把智能体数量拉满就能解决，人仍然需要在关键节点上校准方向。

7.2 人的角色为什么像"HR + 架构师 + 审稿人"

他后来把自己的工作方式形容得很像在管理一个团队：让 Agent 汇报进展、比较方案优劣、要求反思偏差。这个比喻虽然夸张，但点出了人类在 Agent 流水线中的新职责：

1. 设定目标和评价标准。
2. 分配任务和资源。
3. 判断哪些路线值得继续，哪些需要中止。
4. 对关键设计做最后裁决。

人从执行层上移到了组织层与裁决层。

7.3 为什么说 Spec 比 Harness 更重要

黄东旭的结论是：无人监督时，模型很容易跑飞；这时一份写得好的 Spec，往往比把多个 Agent 扔进一个群里聊天更重要。

原因有几层：

1. Harness 能增加讨论量，但不能天然提供正确目标。
2. 多 Agent 可以制造更多候选方案，但也会放大歧义和噪音。
3. Spec 能把"到底算完成"“哪些边界不能碰"提前写死，这是长程任务里最稀缺的稳定器。

Harness 像放大器，Spec 像定盘星。没有定盘星，放大器只会把错误方向放大；没有放大器，定盘星也推不出高质量结果。两者要配着用，但 Spec 是前提——方向错了，放大再多也是浪费。

把这两者放到具体场景里看更清楚。假设你要让 Agent 给一个分布式数据库加在线 DDL（数据定义语言，Data Definition Language）限流：

Harness 决定的是 Agent 能不能同时拉起方案设计、代码实现、测试编写三条线，能不能在跑偏时自动重试。

Spec 决定的是"限流粒度按字节量还是按批次行数"“灰度开关默认值是开还是关"“非限流租户不受影响"这些边界。

Harness 把 Agent 的产出能力拉满，但拉满之后产出的是不是你要的东西，仍然由 Spec 兜底。

一个团队如果只升级 Harness 不升级 Spec，常见的结果是 CI 跑得越来越快、Token 烧得越来越多，但每次回滚的原因还是"Agent 把限流加错了位置”。

7.4 “大力出奇迹"到底该怎么理解

“大力出奇迹"很容易被读成粗暴堆 Token。更合理的理解是：在复杂问题上，不要过早抠搜探索成本，应该用足够多的试错、重写、比较和评审去换跃迁式提升。

这里有两个前提容易漏掉：

1. 没有评估回路，更多产出只是更多噪音。
2. 不是所有任务都值得投入高强度搜索，需要区分对待。

7.5 模型智商与长程任务稳定性

黄东旭强调，在成千上万步的长程任务里，模型能力哪怕只差一点，最终也会被级联放大。这意味着：

1. 低价模型未必真的省钱。
2. 任务链很长时，早期的轻微偏航会在后续步骤里反复放大。
3. 长程任务评估不能只看单轮回答，要看持续一致性、回滚能力和纠偏成本。

7.6 一个任务如何流过系统

看一个典型基础软件任务在 Agent 流水线里怎么走。以下为示意性流程，用"为分布式数据库添加在线 DDL 限流"这种常见任务作样本：

[人] 写一页 Spec
  ├─ Goal: 在线 DDL 执行时按租户限流，避免大表改写压垮存储节点
  ├─ Non-goals: 不做离线 DDL 调度，不改写现有 OnlineSchemaChange 内核
  ├─ Context: 指向 ddl_scheduler.go、租户配额表设计文档、上一轮限流方案被否决的原因
  ├─ Constraints: 必须通过现有 backfill 回归测试；不能引入新依赖；改动需灰度开关
  └─ Acceptance: 限流生效后压测吞吐下降曲线符合预期；非限流租户不受影响

[Agent] 读 Spec，输出方案分解和风险点
  └─ 风险点示例: 现有限流钩子位置在 SQL 层，DDL 路径绕过了它

[人] 补 Context: 确认 DDL 走的是异步 backfill worker，限流要加在 worker 拉取批次处
  └─ 删掉无关的 SQL 层限流历史文档，避免 Agent 跑偏

[Agent] 实现第一版，跑测试
  └─ CI 红了两个: 灰度开关默认值写反、限流计数器在 backfill 重试时没重置

[人] 只审关键设计: 限流粒度选"批次行数"还是"字节量"？决定用字节量，更稳
  └─ 不逐行纠缠代码风格

[Agent] 修问题，重跑测试，全绿

[人] 决定: 灰度上线一个租户观察一周，再扩量

这个流程里有几个关键点：

1. Spec 是起点也是锚点。Agent 每次跑偏，人都可以把它拉回 Spec，而不是每次重新解释意图。
2. Context 是动态的。第一轮 Agent 输出的风险点，反过来帮人发现"原来缺这块背景”，于是补 Context、删无关材料。这是双向的。
3. Constraints 在测试里兑现。CI 红了不是失败，是约束在起作用——没有这些约束，Agent 会"自信地"交付一个灰度开关写反的版本。
4. 人只审关键设计。限流粒度这种决策，Agent 给不出业务侧的判断；但代码风格、变量命名这类事，人不该再逐行纠缠。

少了任何一环，这个流程都会退化：没有 Spec，Agent 会在"限流"这个词上自由发挥；没有 Constraints，CI 不会拦住灰度开关写反；没有人在关键设计上裁决，Agent 可能选了"批次行数"这种在长文本场景下不准的方案。

把上面流程里"人写 Spec"那一步落成可机器解析的文件，下面这份 YAML（数据序列化格式，YAML Ain’t Markup Language）可以直接喂给支持 Spec 驱动的 Agent 工具链（如 Claude Code、Cursor Rules 或自建 Harness）。字段对应 §15.2 的最小模板，只是换成了结构化格式，方便 Agent 解析和回填风险点：

# spec_ddl_throttle.yaml
# 任务：为分布式数据库添加在线 DDL 限流
# 用法：作为 Agent 的输入 Spec，配合 CI 回归测试与灰度开关使用

goal: |
  在线 DDL 执行时按租户限流，避免大表改写压垮存储节点。

non_goals:
  - 不做离线 DDL 调度
  - 不改写现有 OnlineSchemaChange 内核逻辑

context:
  code_paths:
    - pkg/ddl/ddl_scheduler.go
    - pkg/ddl/backfill_worker.go
  related_docs:
    - docs/design/tenant_quota.md
  history: |
    上一轮限流方案被否决，原因是加在 SQL 层，DDL 路径绕过了它。
    本轮限流必须加在 backfill worker 拉取批次处。

constraints:
  must_pass_tests:
    - test/ddl/backfill_regression_test.go
  no_new_dependencies: true
  feature_flag: ddl_throttle_enabled  # 默认关闭，灰度开启
  rollback: revert commit + 关闭 feature flag

acceptance:
  - 压测下限流租户吞吐下降曲线符合预期斜率
  - 非限流租户吞吐波动小于 5%
  - backfill 重试时限流计数器正确重置

review_focus:
  - 限流粒度选"字节量"而非"批次行数"（人裁决）
  - 灰度开关默认值必须为 false

这份 Spec 文件可以直接提交到仓库的 specs/ 目录下，配合 CI 检查 feature_flag 默认值、运行 must_pass_tests 列出的测试，就构成了一个最小可运行的"Spec + Constraints"闭环。

注意：上面的代码路径、测试文件名是示意，实际使用时替换成你仓库里的真实路径。

若 Agent 工具链不支持 YAML Spec，也可以用 Markdown 格式按 §15.2 的模板写，关键是字段齐全、可被 Agent 引用。

§8 软件形态如何变化：从固定界面到意图驱动

8.1 静态软件的前提正在松动

传统软件大多建立在一个前提上：功能边界、页面路径、操作顺序，都是产品团队预先决定好的。用户要学的是"这个系统允许我怎么做”。

LLM 和 Agent 介入之后，这个前提正在松动。

用户越来越可能先表达意图，再由系统临时组织路径。黄东旭那句判断就指向这里：

**趋势：**未来软件的主要接口，会从固定 UI 扩展到"用户想达到什么结果”。

这不是说 UI 会消失，而是说 UI 不再是唯一入口。一个典型例子：过去你要导出报表，得先登录、找菜单、点导出、选格式、等邮件。以后你可能只说一句"把上个月的销售报表发我邮箱”，系统自己把路径组织好。

8.2 这不意味着 UI 会消失

意图驱动不等于界面消失。界面从"唯一入口"变成"多入口之一"。

在很多高风险、高反馈密度的场景里，UI 仍然重要，因为它提供：

1. 过程可见性。
2. 关键动作确认。
3. 状态切换反馈。
4. 低成本纠错路径。

UI 不再垄断交互入口，但不会消失。意图入口和界面入口会长期共存，谁占主导取决于场景的风险密度和反馈频率。

8.3 OpenClaw 作为 60 分基线的含义

黄东旭把 OpenClaw 当作一种基线样本来谈，它代表了一种判断标准：如果新一代软件的灵活度和操作体验还不如 Agent 原生工具，那它就仍然停留在旧范式。

OpenClaw（https://openclaw.ai）是一个面向 Agent 操作的开源工具项目，定位是给 Agent 提供可调用的浏览器与系统操作能力，常被用作衡量"Agent 原生交互体验"的参照样本。本文引用它仅作为基线参照，不代表对其稳定性、维护状态或商用可行性的背书。

未来用户会拿你和"能听懂意图、能自动串流程、能快速试错"的系统做对比，而不只是拿你和传统软件做对比。

8.4 Unix 哲学的回归

黄东旭特别推崇 Unix 风格，因为它天然适合被 Agent 使用：

1. 工具职责清晰。
2. 输入输出结构明确。
3. 组合成本低。
4. 改需求时不必重做整个界面。

对 Agent 来说，CLI 与结构化文本往往比复杂图形界面更容易理解、更容易组合，也更适合自动化试验。“可组合性"会重新成为软件设计中的硬指标。

§9 产业格局会怎样重排

9.1 中间层被挤压的逻辑

黄东旭给出的判断是：**趋势：**当 Agent 普及后，很多位于"人和机器之间"的中间层 SaaS 或行业软件，会面临更强的压缩。

逻辑是这样的。

靠近人的一端，比拼的是意图理解、体验、情绪价值和控制感。用户会问"你能帮我做到吗”，而不是"你的菜单在哪里"。

靠近机器的一端，比拼的是稳定交付、接口清晰、吞吐和基础设施能力。系统会问"你的 API 是否可调用、是否稳定、是否便宜"，而不是"你的页面好不好看"。

夹在中间、主要靠流程包裹和页面包装提供价值的产品，会被上下两端同时侵蚀。因为它既不最懂人的意图，也不最懂机器的执行。

中间层要活下去，得重新证明自己不可替代——光靠"把旧流程包进新界面"已经不够了。

9.2 “没有账号体系"反映了什么

他提到 TiDB Cloud 的新产品线 Zero（参见 TiDB Cloud 官网），强调的是一种 Agent-first 的思路：如果未来发起请求的主体越来越多是 Agent，而不是人，那么围绕"人类登录流程"设计的很多默认前提都会变成摩擦。

**趋势：**越来越多基础设施会朝"随调随走、弱人工配置、适合机器调用"的形态演进。

9.3 “Everything is Skill” 提醒了什么

“把一段 Skill 贴进对话框，它就自己跑起来"这类说法，描述的是一种新的交付体验：不用先教人点哪里，而是先让系统知道该做什么。

软件分发、上手和集成的最小单位都可能变化。过去的最小单位是安装包、账号和配置页面；未来的最小单位可能更接近一段可执行的任务说明、工作流模板或可组合能力包。

§10 Skill 为什么不够，下一代抽象需要什么

10.1 Skill 的价值与局限

黄东旭认为 Skill 很重要，但也很粗糙。Skill 的优点和缺点来自同一个地方：它足够轻，所以传播快；但也因为太轻，难以承载复杂系统。

当任务只是"教系统完成一个相对明确的小流程"时，Skill 很有效。但当软件开始涉及多角色协作、多系统编排、长期状态、审计、回滚和复杂权限时，单张"配方卡片"就明显不够用了。

10.2 下一代抽象至少要满足什么条件

下一代抽象至少应该满足 4 点：

1. 能表达复杂协同，而不只是单次提示词。
2. 本身有足够结构化的形态，但可以被自然语言生成和修改。
3. 不只能黑箱运行，还要能被调试、被审计、被测试。
4. 把领域经验蒸馏成可复用的生产资产，而不只是把流程记下来。

10.3 从 App 到 Stack，意味着什么

黄东旭举了厨师做 Cooking Stack 的例子。这个例子的启发在于软件创业门槛的变化：**趋势：**未来某个领域专家真正卖的，可能是一套被蒸馏过的工作流、判断标准、知识结构和自动执行能力，固定界面的 App 反而退居其次。

**趋势：**未来很多软件产品的竞争力，会落在"把专家经验编译成可调用系统"这件事上。

§11 朴素工程经验为什么反而更值钱

黄东旭有一句话点出了 Agent 时代工程能力的位置：Harness Engineering 翻译过来，很多时候其实就是"Still Good Engineering”。

Agent 时代没有消灭软件工程，反而把以下能力推到了更前台：

会被淘汰的是那种把工程能力等同于"手写代码速度"的理解。工程能力本身不会。

§12 再往前推一层：程序员能力迁移图

Coding 本身不会消失，变化的是它在工程工作里的位置还会继续下降。代码还在，但那些低杠杆、可模板化、可局部优化的实现劳动，未来大概率不会像今天这样值钱。

12.1 哪些能力会快速贬值

下面这些能力不会彻底消失，但市场议价能力会明显下降：

这些能力不会突然没用，但很难再单独支撑一个高价值工程师的定位。

12.2 哪些能力会快速升值

直接影响结果质量、系统边界和长期演化方向的能力会更稀缺：

12.3 未来顶级工程师更像什么样的人

未来最强的工程师，更像 4 种角色的叠加：

1. 总工程师：负责系统结构、边界与演化方向。
2. 评估设计者：负责定义什么叫完成、什么叫失败、什么叫越界。
3. 审计与治理负责人：负责权限、回滚、责任归属与证据链。
4. 委托系统设计者：负责把人类目标翻译成 Agent 可持续执行的工作流。

未来你主要是对代码负责，还是对结果、风险和演化负责？后者会越来越重要。

12.4 一个更尖锐的判断

程序员这个职业不会消失，但岗位重心会明显变化。只负责把代码写出来的角色更容易被边缘化；能让人、模型、工具和规则稳定协同的人，才会变稀缺。

§13 AI 软件产业链重组图

前面提到中间层 SaaS 会被挤压。

被压缩的未必是所有中间层，更可能是那些主要靠页面包装提供价值的中间层；和治理、控制、审计相关的中间层，重要性反而可能上升。

13.1 被压缩的是哪一类中间层

更容易失去位置的产品，是那些既不掌握真实执行接口，也不掌握治理规则，只是把旧流程重新包进一套界面的产品。

这类产品会被两头同时挤压：

1. 向上，被意图入口吃掉，因为用户越来越不想自己找按钮。
2. 向下，被执行基础设施吃掉，因为真正完成任务的能力在底层接口和工作流编排里。
3. 向内，被企业自建 Agent 流程吃掉，因为一旦工作流可编排，很多"页面包装价值"会失去独立性。

13.2 未来软件会重新分成哪四层

按 Agent 时代的软件结构重画，可以分成下面四层。这个分法不一定终极，但至少帮你把"到底缺哪一层能力"说清楚：

举一个具体例子来理解这四层。

假设你对系统说"帮我订明天去上海的机票”：

• 意图层 要澄清：经济舱还是商务舱？哪个机场？有没有偏好航空公司？
• 治理层 要检查：你的预算够不够？有没有审批流程？支付权限是否开启？
• 执行层 要调用：机票搜索 API、支付接口、日历系统、邮件系统。
• 环境层 要提供：你过去的座位偏好、常飞的航空公司、公司差旅政策。

**趋势：**未来真正有优势的软件公司，往往不会只停留在其中一层，而是至少把"意图 + 治理"或"治理 + 执行"两层打通。

13.3 哪些能力会变得更贵

长期看，下面这些能力会更贵：

1. Agent 身份、权限与委托体系。
2. 可审计、可回滚、可解释的执行基础设施。
3. 企业长期记忆与知识沉淀系统。
4. 多 Agent、多工具、多环境的编排层。
5. 执行前评估、模拟、对照和压力测试系统。
6. 对真实世界接口的控制力，比如支付、数据库、文件、工单、供应链和设备系统。

过去很多软件卖的是"功能页面"，未来越来越多软件卖的，可能会是"从目标到结果的一整段可追责流程"。

§14 比"Coding 已死"更远的终局判断

14.1 长期看，验证可能比生成更稀缺

现在大家最容易关注的，是模型能不能写更多代码、完成更长的任务。把时间拉长，**趋势：**生成能力大概率会越来越便宜；难的是另一组问题：

1. 你怎么确认它做的是对的。
2. 你怎么确认它没有碰不该碰的边界。
3. 你怎么确认它在长时间运行里还能保持稳定。
4. 你怎么确认它的成本、时延和风险都在可接受范围内。

下一代关键基础设施不只是更强的模型，还包括评估体系、审计日志、权限控制、证据留存和回滚机制。缺了这些，Agent 很难真正进入生产流程。

14.2 未来的软件，卖的可能不只是"功能"

传统软件更像在卖功能模块，这里一个页面，那里一个按钮。到了 Agent 时代，**趋势：**更有价值的可能是从"提出目标"到"拿到结果"的整段流程。

用户真正关心的是这套系统能不能稳定把一类事情做完，而且做得足够快、成本可控、出了问题还能追溯。功能清单的长度反倒退居其次，能不能把结果做出来才是真正的竞争力。

14.3 强的 Agent 系统，更像一个能持续运转的组织

一个真正强的 Agent 系统，更像一个能持续运转的小型组织，里面有目标、记忆、工具、权限、预算、评估和回滚机制。

会聊天的 App 只是它的表层形态，真正起作用的是底下那套组织机制。

它至少要回答下面这些问题：

1. 这次到底要完成什么。
2. 需要哪些历史信息和上下文。
3. 可以调用哪些工具。
4. 权限边界在哪里。
5. 预算和成本怎么控制。
6. 结果由谁评估、如何审计。
7. 失败之后怎么回滚和修正。

**趋势：**未来被重新设计的不只是软件界面本身，还包括任务怎么被拆解和排程、能力怎么被组合调用、出了问题责任怎么追溯到具体环节。

14.4 把判断压成一句话

比"Coding 已死"更深一层的判断：

未来最大的变化，是越来越多原本靠人来协调的事情，会被整理成可以交给系统执行、检查和迭代的流程。AI 会不会写代码反而成了次要问题。

这句话指向的是组织方式变化，职业动作只是表层。代码仍然重要，但越来越像执行层；真正被重写的，是人如何把目标、规则、资源和责任组织起来交给系统。

§15 把观点落地：一套可直接试运行的实践清单

把这篇文章的观点转成团队试验，可以从下面这套最小闭环开始。

15.1 先选一个适合试点的任务

优先选择满足下面条件的任务：

1. 边界清晰。
2. 可以独立验收。
3. 有现成测试或至少能写出回归验证。
4. 出错后可以回滚，不会直接造成生产事故。

第一批试点通常不适合下面这类任务：

1. 权限过高，一旦误操作就会直接改动生产数据。
2. 历史债务极重，连人类都说不清边界。
3. 验收标准模糊，只能靠"感觉差不多"。
4. 一旦失败就难以回滚，或者代价极高。

15.2 写一页就够用的最小 Spec

下面是一份足够实用的最小模板：

Goal:
- 这次要完成什么结果

Non-goals:
- 这次明确不做什么

Context:
- 相关业务背景
- 相关代码路径 / 历史设计决策
- 参考实现或约束来源

Constraints:
- 不能修改哪些边界
- 必须通过哪些测试
- 允许使用哪些工具 / 权限

Acceptance:
- 什么结果算完成
- 用什么方式验证

Rollback:
- 如果方案失败，如何撤回

这份模板直接对应 Goal、Context、Constraints 三个核心维度，专门对付"系统很努力，但一直做偏"的情况。

15.3 建一个最小评估回路

一个可运行的 Agent 试点流程，至少要包含下面 7 步：

1. 人类先写 Spec。
2. Agent 给出方案分解和风险点。
3. 人类补充缺失 Context，并删掉无关材料。
4. Agent 实现第一版。
5. 自动化测试、Lint 和静态检查先跑一轮。
6. 人类只审关键设计、边界和异常路径，不逐行纠缠。
7. 根据结果决定继续迭代、回滚还是扩展范围。

没有评估回路，“大力出奇迹"就会退化成"大力制造噪音”。

15.4 落地案例与量化参考

§7.6 的 DDL 限流任务流展示了 Spec、Context、Constraints 在一次任务里如何协作。团队自测时，建议先固定三个量化指标做前后对比：Agent 任务一次通过率（CI 全绿且无需返工的任务占比）、平均返工轮次、单任务 Token 消耗。跑满 4 周再下结论。

一个可操作的落地节奏：第 1 周只跑最小 Spec 模板，记录基线；第 2 到 3 周引入 7 步评估回路，观察返工轮次变化；第 4 周复盘，决定扩范围还是收紧 Spec。如果三项指标都没有明显改善，问题大概率出在 Spec 质量或 Constraints 缺位，而不是模型能力。

§16 容易误读的四句话

• “Coding 已死”≠“程序员不需要懂系统了”：系统理解力、边界意识和抽象能力会更重要，因为人类正在上移到定义目标、约束系统和做最终裁决的位置。
• “大力出奇迹”≠“无限堆 Token”：缺了评估体系、阶段性验收和高质量问题定义，堆再多 Token 也只是更昂贵地迷路。
• “Everything is Skill”≠“软件分发问题已经解决”：Skill 可以降低上手摩擦，但权限、状态、审计、合规、可维护性这些问题仍然存在。
• “组织可以被编程”≠“人类可以退出系统”：人类仍然承担裁决、问责和价值判断。Agent 会放大组织能力，也会放大组织错误。

§17 总结

黄东旭的判断可以浓缩为一句话：生成能力会越来越便宜，验证与治理会越来越贵。代码还在，但代码作为思考媒介的垄断地位正在松动。

对于软件工程师，这意味着从"写得快"升级到"目标讲得清、边界立得住、结果审得准"。对于技术负责人，预算应该投向评估体系、约束体系和治理层，而不是更多调用量。对于创业者，检查你的产品价值——到底是靠界面包装，还是靠真实不可替代的知识和执行能力。

如果团队想从零开始试，建议顺序是：先补 Constraints（测试、CI、回滚、权限），再练 Spec，然后建评估回路，最后扩范围。每一步跑通再进下一步。这套方法适合边界清晰、可验收、可回滚的工程任务，不适用于验收标准模糊或失败代价极高的场景。

本文基于黄东旭在 2026 年 4 月 QCon 全球软件开发大会上的主题演讲《The Age of Autonomous Systems（自主系统的时代）》整理。黄东旭是 TiDB 联合创始人兼 CTO，观点源自高强度一线实践，文中趋势推演部分需要更多行业样本验证。延伸阅读：Anthropic Claude Code、OpenClaw、TiDB Cloud。