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

定位：这不是一篇泛泛谈论“AI 会不会替代程序员”的评论文，而是把黄东旭在高强度 Agent 实战后的观点，整理成一篇更适合工程师阅读、评估与试运行的方法论笔记。 目标读者：软件工程师、技术负责人、AI 产品与基础设施从业者，以及关注 Agent 时代软件形态变化的读者。 前置知识：软件工程基础，理解大语言模型、Agent、测试与交付流程的基本概念。 难度定位：⭐⭐⭐⭐，偏进阶与方法论分析。 预计阅读时间：35 到 50 分钟。

§1 先给结论

如果你时间有限，可以先记住下面 8 点：

1. “Coding 已死”更准确的含义，不是编程知识失效，而是代码正在从“人类主要思考媒介”退到“AI 负责生产的执行载体”。
2. Agent 时代最稀缺的能力，不再只是写代码，而是把 Goal、Context、Constraints 讲清楚。
3. 多 Agent 协作并不天然提升质量；缺少高质量 Spec 和验收标准时，系统只会更快跑偏。
4. 软件形态会从固定界面走向意图驱动，但这不代表 UI 消失，而是 UI 退居辅助层。
5. 产业机会会向两端集中：一端更贴近人的意图与体验，另一端更贴近机器执行与基础设施。
6. Skill 大概率只是过渡抽象，下一代交付物更像可组合、可调试、能蒸馏专家知识的 Stack。
7. 程序员不会消失，但会快速分化；低杠杆实现劳动会贬值，对结果、验证和边界负责的工程师会升值。
8. 长期看，生成能力会商品化，验证与治理能力会变成真正稀缺的基础设施。

§2 学习目标

完成本篇文章后，你将能够：

1. 理解“代码从思考载体变成执行载体”这句话到底意味着什么。
2. 掌握 Goal / Context / Constraints 这套三维分析框架，并能映射到真实工程场景。
3. 看清 Agent 时代软件形态为什么会从静态界面转向“意图驱动”。
4. 理解人机协同的正确姿势，知道为什么人不是甩手掌柜，而更像架构师加审稿人。
5. 分辨哪些观点是经验结论，哪些只是趋势判断，避免把强表达误读成已证实事实。
6. 把文章中的抽象观点转化成一套能在团队中试运行的实践清单。
7. 理解未来 5 年程序员能力结构会怎样迁移，哪些能力会贬值，哪些能力会升值。
8. 看懂 AI 软件产业链可能如何重组，以及为什么治理层会比页面层更重要。

2.1 阅读指引

如果你的关注点不同，可以这样读：

§3 信息来源与阅读边界

在进入正文前，先明确 3 个边界，否则很容易把这篇文章读成“行业定论”：

1. 本文基于黄东旭公开表达的整理与分析，既包含其自述实践，也包含他对行业方向的强判断。
2. 文中涉及“未来一定怎样”的部分，更适合被理解为高强度一线实践后的工作假设，而不是已经被全行业验证的定理。
3. 引语按现有材料整理，适合用于理解观点，不适合在缺乏原始出处核对时直接当作学术式引用。

为了方便阅读，你可以把全文中的内容分成 3 类：

这一步很重要，因为它直接决定你读完后是“被观点震住”，还是“知道哪些能立刻拿来试”。

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

4.1 为什么这个案例值得看

黄东旭是 TiDB 联合创始人兼 CTO，工程师出身，长期参与一线技术工作。他这轮分享之所以值得注意，不是因为头衔本身，而是因为它同时具备下面 3 个特征：

1. 不是做简单 Demo，而是围绕复杂基础软件展开。
2. 不是只谈模型能力，而是谈长程任务、协作方式、约束体系和交付结果。
3. 不是把 Agent 当效率插件，而是把 Agent 当作一个需要被组织、被管理、被约束的“软件生产系统”。

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

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

这两个信息真正重要的地方不在于“数字有多大”，而在于它们分别指向两个判断：

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

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

黄东旭明确强调，消耗多少 Token 不应该被当成目标。更有价值的衡量方式是：你最终交付了什么，它是否可用，它是否让某类复杂任务的完成方式发生了变化。

这句话值得单独拎出来，因为它直接击中了很多团队现在的误区：

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

如果没有可运行结果、可验收标准和可回滚路径，Token 只是一种成本，不是生产力证明。

§5 如何理解“Coding 已死”

“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，之所以值得记住，是因为它能把很多零散讨论重新归位。

6.1 一张表看懂三维分工

这张表的价值在于，它把“为什么 Agent 表现不好”从模糊抱怨变成了可诊断问题：

1. Goal 不清，系统会勤奋地做错事。
2. Context 不够，系统会高置信地瞎补。
3. Constraints 太弱，系统会把局部最优写成整体事故。

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

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

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

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

这也是为什么现在很多看起来在做“人机交互”的产品，实质上都在试图降低 Goal 表达成本。

6.3 Context：不是喂得越多越好，而是喂得越准越好

Context 并不只是“把仓库全塞进去”。真正有价值的 Context，通常具有 3 个特征：

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

黄东旭提到的 Memory、RAG、Harness Engineering、本质都在解决“如何让 Agent 拿到正确的前提”。Context 是今天最卷的方向，但也是最容易被误做成“堆料工程”的方向。

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

如果说 Goal 决定方向，Context 决定理解质量，那么 Constraints 决定系统有没有资格接近生产环境。

常见约束包括：

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

很多团队表面上在研究 Agent，实际上最缺的不是模型，而是 Constraints。因为没有约束，任何“看起来聪明”的系统都很难稳定进入真实业务流程。

§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 才像定盘星。

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

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

这背后有两个隐含前提：

1. 你必须有评估回路，否则只是在制造更多废话。
2. 你必须知道在哪些问题上值得投入高强度搜索，而不是对所有任务一视同仁地铺资源。

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

黄东旭强调，在成千上万步的长程任务里，模型能力哪怕只差一点，最终也会被级联放大。这个判断对团队选型很重要，因为它提醒你：

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

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

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

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

但在 LLM 和 Agent 介入之后，这个前提正在松动，因为用户越来越可能先表达意图，再由系统临时组织路径。

这也是黄东旭那句判断的核心：未来软件的主要接口，不再只是固定 UI，而是“用户想达到什么结果”。

8.2 这不意味着 UI 会消失

这里需要加一个边界：意图驱动并不意味着界面消失，而是意味着界面从“唯一入口”变成“多入口之一”。

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

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

所以，更准确的表述不是“没有 UI 了”，而是“UI 不再垄断交互入口”。

8.3 OpenClaw 为什么会被当作“60 分基线”

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

这句话对产品设计的启发是，未来用户会拿你和“能听懂意图、能自动串流程、能快速试错”的系统做对比，而不只是拿你和传统软件做对比。

8.4 为什么 Unix 哲学会重新变得重要

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

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

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

§9 产业格局会怎样重排

9.1 为什么中间层会被挤压

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

这背后的逻辑是：

1. 靠近人的一端，比拼的是意图理解、体验、情绪价值和控制感。
2. 靠近机器的一端，比拼的是稳定交付、接口清晰、吞吐和基础设施能力。
3. 夹在中间、主要靠流程包裹和页面包装提供价值的产品，更容易被上下两端同时侵蚀。

这当然不是说“所有中间层都会消失”，而是说它们必须重新证明自己不可替代的价值。

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

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

这个例子最值得关注的，不是具体产品机制，而是它揭示的方向：越来越多基础设施会朝“随调随走、弱人工配置、适合机器调用”的形态演进。

9.3 “Everything is Skill” 提醒了什么

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

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

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

10.1 Skill 的价值与局限

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

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

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

如果 Skill 只是过渡层，那么下一代抽象至少应该满足下面 4 点：

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

10.3 从 App 到 Stack，意味着什么

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

用一句更工程化的话说，未来很多软件产品的核心竞争力，可能是“把专家经验编译成可调用系统”的能力。

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

黄东旭有一句话很值得反复咀嚼：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 被压缩的是哪一类中间层

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

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

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

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

如果按 Agent 时代的软件结构重画一遍，我更倾向于把它分成下面四层：

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

13.3 哪些能力会变得更贵

长期看，更值得重视的，不是“再做一个聊天界面”，而是下面这些能力：

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

所以，如果说过去很多软件卖的是“功能页面”，那么未来越来越多软件卖的，可能会是“从目标到结果的一整段可追责流程”。

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

“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 先选一个适合试点的任务

不要一开始就把最核心、最高风险、最强耦合的系统交给 Agent。优先选择满足下面条件的任务：

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 自测问题

读到这里，你可以用 4 个问题检查自己是否真正理解了本文：

1. 为什么 Goal 不清晰，更多 Agent 不一定带来更好结果？
2. Memory、RAG、Harness Engineering 分别属于哪一类问题，它们真正想补足的是什么？
3. “Coding 已死”为什么不等于“基础软件工程知识不重要了”？
4. 为什么长期看生成会商品化，而验证与治理会变成更稀缺的能力？

如果这 4 个问题你能用自己的语言回答出来，这篇文章就已经从“观点输入”变成了“框架内化”。

§16 容易误读的四句话

16.1 “Coding 已死”不等于“程序员不需要懂系统了”

相反，系统理解力、边界意识和抽象能力会更重要，因为人类正在上移到定义目标、约束系统和做最终裁决的位置。

16.2 “大力出奇迹”不等于“无限堆 Token”

没有评估体系、没有阶段性验收、没有高质量问题定义时，堆再多 Token 也只是更昂贵地迷路。

16.3 “Everything is Skill”不等于“软件分发问题已经解决”

Skill 可以降低上手摩擦，但权限、状态、审计、合规、可维护性这些问题仍然存在。复杂软件的交付，不会永久停留在“贴一段提示词”这一层。

16.4 “组织可以被编程”不等于“人类可以退出系统”

组织被编程，指的是目标、规则、权限、证据链和执行流程可以被结构化表达，而不是说人类不再承担裁决、问责和价值判断。Agent 会放大组织能力，也会放大组织错误。

§17 总结与行动指引

17.1 核心判断回顾

17.2 给 3 类读者的直接建议

对软件工程师

1. 把“写得快”升级成“目标讲得清、边界立得住、结果审得准”。
2. 主动训练写 Spec、写验收标准、写风险清单和设计评估回路的能力。
3. 不要把 Agent 当补全工具，而要把它当一个需要持续治理的生产系统。

对技术负责人

1. 不要只看单点提效，优先看长程任务的稳定性、回滚成本、验证链路和质量门槛。
2. 把预算投向评估体系、约束体系、治理层和高质量上下文管理，而不是只投向“更多调用量”。
3. 让试点任务先在低风险、高可验收模块中闭环，再扩到核心系统。

对创业者 / 产品负责人

1. 重新检查你的产品价值，到底靠界面包装、流程包裹，还是靠真实不可替代的知识、治理和执行能力。
2. 思考你交付给用户的最小单位，未来是否会从“页面和按钮”变成“任务闭环和工作流”。
3. 尽早关注 Agent 的治理体验，也就是如何让系统更顺畅地理解、调用、审计和接管你的产品能力。

相关资源

• 原文主题：TiDB 黄东旭关于 Agent 时代软件构建、软件形态与未来发展的公开思考。
• 作者：黄东旭，TiDB 联合创始人兼 CTO。
• 延伸阅读：Anthropic Claude Code
• 延伸阅读：OpenClaw
• 延伸关注：黄东旭的公开分享与微信公众号相关文章。