跨国深谈← 返回←AWS 杰出工程师：智能体时代，难的不是写代码，是写规格

AWS 杰出工程师：智能体时代，难的不是写代码，是写规格

关联

人物 Marc Brooker · Simon Maple

公司 AWS · Strands · Agent Core · Dogwood

概念 智能体 · on call · 事后分析 · 智能体政策 · 规范 · Oracle · 测试 · 智能体记忆 · RAG

这一集的主角是 Marc Brooker——他在 AWS 待了 18 年，现在是 VP 兼杰出工程师，最近几年专注智能体 AI 的基础设施，深度参与了 AWS Agent Core(一套在云端构建智能体的工具套件)，并负责开源智能体框架 Strands。而开场最有分量的一句话来自主持人的提问背景：他做过 15 年 on call(生产系统值班)，读过上万行级别的 3000 到 4000 份复盘报告(postmortem,事故后的分析文档)。一个写了半辈子底层系统的人，怎么看智能体接管软件开发的未来？

on call 不会被取代，但值班的内容在变

Brooker 的判断是：机械重复的部分会被自动化掉，这不是新鲜事。15 年前，单台主机故障还会把人呼叫起来，后来 autoscaling(自动扩缩容)和负载均衡器健康检查替我们把这些处理掉了。AI 正在做同一件事——日志抓取、钻取指标这类日常调查，AWS 的 DevOps 智能体已经做得很棒 。

剩下的是真正有意思的推理：为什么系统表现成这样？我们在大规模故障里看到了什么？

自动化今天还回答不了这些问题 。主持人的愿景是：凌晨 3 点被叫醒时，智能体已经翻完了日志、找出了可能的根因，把决策所需的信息摆在面前——这正是行业正在逼近的形态。

4000 份复盘教会他的事

读几千份复盘，最大的收获是「一种深深的谦卑感」：工程师天性乐观，这是好事，但看过系统怎么失败之后，你会带着「我知道这肯定会出问题，只是不知道怎么出、什么时候出」的心态写代码 。

一个具体的例子是亚稳态失效(metastable failure):大系统出事宕机后，直接原因修好了，系统却卡在稳定的宕机状态里起不来。理解这类失效的唯一途径，就是盯着真实事故问：是什么把系统踢进这种状态？

是什么让它起不来？是什么最终带来了恢复？ 这些知识没法纯靠理论推出来。

智能体能不能学复盘？Brooker 说非常现实，而且就是当前前沿正在发生的。路径有四条：把复盘放进训练集；给智能体一个语义搜索工具(「给我看类似这样的事故，当时是怎么恢复的」)；让智能体写自己的记忆(「试了 X 没用，试了 Y 成功了」)；最有趣的是程序性记忆——智能体把自己走过的每一步编码成一段代码、做成工具存起来，下次直接拿来用 。

更深一层，Amazon 一直坚持「谁构建、谁值班」，就是为了让生产经验直接流回开发。Brooker 押注的是：未来的编程智能体，也能和运维智能体以完全相同的方式从生产经验中学习——共享记忆、共享工具，甚至请开发智能体当专家顾问来评审软件设计。但他说，行业在这条路上，比优化单个部件要早期得多 。

给智能体立规矩：确定性的边界

客户最常见的痛苦是：demo 做得很炫，董事会很兴奋，但没人敢让它进生产——怎么让客户信任一个代表他们干活的智能体？

Brooker 的答案是「智能体政策」：清晰、确定性地定义智能体能做什么、不能做什么、能按什么顺序做。传统授权语言(把人类权限管起来的那套)不够用，因为人靠判断力补足了规则管不到的地方，智能体没有。所以 AWS 刚发布了 Dogwood,一种专门语言，用数学上的确定性描述智能体的行为边界 。

这里有个反直觉的洞见：让人类盯着智能体、坏事发生时按红色按钮，是行不通的。几十年心理学和运营研究证明，人类是非常糟糕的监督者 。

80 年代的经典论文《自动化的讽刺》就指出：系统越好，失效模式越怪异越罕见，人类监督者越难识别和正确反应。所以唯一的出路是把人从回路里拉出来——别让人类在每个代码生成任务后说「是、是、是」，因为根本没人会真的那么干 。

那边界从哪来？三种方式：把常识编码进策略(智能体只该在自己工作的仓库里做 push,跑去别的仓库 push 多半是坏的)；自然语言转策略(「它可以读我硬盘上任何东西，除了机密文档文件夹」被自动可靠地转成策略)；以及走遍公司，把现有规范编码成策略。直接写策略语言的会是少数，绝大多数人在自然语言层面说「什么是好的」。

政策来源大约是 50-50:一半来自组织和法务、安全团队(客户内容怎么处理，每个开发者的智能体都必须遵守)，一半来自个人(我的智能体能不能删我文档文件夹里的文件？安全团队不在乎，我在乎)。而且政策必须动态、情境化——写后端 Rust 时可以规定「Clippy(代码检查工具)不满意不许提交」，写 15 分钟就扔的 demo 原型时就什么都不用设 。

难的部分是规格，测试成了最重要的环节

Brooker 提出的「智能体软件开发假说」核心是：软件构建中难的部分是规格构建(specification)——把你要的东西描述得足够完整。一旦规格写下来，可靠、高效实现的构建和维护，会随着时间推移完全自动化 。先从封闭规格开始(「实现这种文件格式」)，再扩展到更大、有更多 UI 和复杂交互的系统。

那难的部分只是被搬家了吗？主持人问得尖锐。

Brooker 承认：创建 oracle(判定「做出来的东西对不对」的标准)和规格，就是人类工作大量所在之处。实现 GZIP 这种东西可以完全形式化，给客户做 UI 就不行，得用更开放式的评估——生产指标、客户反馈、甚至对同一数据库引擎的两个实现做模糊测试对比。

所以他下了个重磅判断：「在某种意义上，测试现在是软件开发中最重要的部分。它从来都不是大多数开发者眼中耀眼的东西，但现在，思考如何构建一个能判断这段软件好不好的测试，真的就处于软件开发的前沿。」 他还嫌当前的规约驱动开发(如 Kiro 团队做的)混淆了声明式需求和实现细节——规格和测试应该聚焦「软件的输出什么样子算好」，而不是内部怎么实现；作为系统构建者，他不想关心用什么语言，他要的是伟大的决策被更自动地做出 。

一条清晰的个人边界：AI 能写我的代码，不能写我的博客

Brooker 至今不让 AI 写博客里的一个字，但很乐意让它写代码。他的解释是意图的区别：五年前他会说，大多数代码的目的是与人类沟通；而现在，随着人类退出代码层、进入规约层，「代码正越来越多地变成纯粹的实现载体，而不是沟通载体」。

博客则不同，背后是一份社会契约：我花大量时间深入思考这些文字，读者花时间深入理解它们。「如果我用 Claude 五分钟写一篇博客，然后 1 万人各花 10 分钟读它，我投入的努力和读者投入的努力之间存在巨大的不对称——我认为那是不公平的。」 如果你想分享 AI 对某个想法的看法，那就做成互动的：把提示词发给我，我们一起追问——别落在那个尴尬的中间地带，去掉了人类的用心，又没加上互动性。

对工作文档他有一条实用的分界线：把 Claude 当扩写器(「把这个提示词变成六页文档」)是浪费读者时间；当上下文提供者(「加一段本周业务指标」)完全没问题——因为新信息是你提供的，形式和你本来会手动做的一模一样 。至于个人博客，那是一件手艺活，他想留住它。

团队今天就能做的：把反馈信号做清晰

不同成熟度的团队该干的事不一样。刚起步的团队，别眼高手低：在 agents.md 文件里写下「什么是好的」，是人们现在会翻白眼但被证明非常有效的东西；「Clippy 满意并通过所有测试之前不许发布代码」这种门禁，开销极小、效果极大——很多团队却急着跳去做参数化记忆 。

往上走，关键是个体记忆解决不了的问题：智能体的记忆没法在团队间传播。所以现在流行「智能体 wiki」模式——让团队智能体维护一个小 wiki,记录「什么是好的」，在智能体之间共享；还有像 AWS Context 这样的工具，让智能体把环境上下文建成形式化图，连回记忆和文档，在整个组织范围共享。他特别提醒：人们嘲笑 RAG(用语义搜索检索组织内部资料)过时了，「但底线是，让智能体对我组织中的信息进行语义搜索，仍然是一种非常强大的技术」。

为什么要给年轻人留梯子

给初级工程师的建议是：负责一个项目，和客户交谈，承担一个截止日期——这些恰恰是高级工程师过去常常把持的任务。他们该交出来吗？

Brooker 的回答是：必须交。「软件行业未来十年会在重要性和经济影响上大幅增长，但如果我们把梯子抽掉，让软件工程师群体变得越来越灰白，就不会有那种增长。

」 经验和深厚专长仍然极重要，但行业的成功取决于能不能把理论新鲜、实践空白的毕业生快速带上手。这将是未来组织的巨大差异化因素。而且这批 AI 原生的年轻人没有旧包袱，带来的是纯新的视角——连老手都该向他们学习。

本集带走

• 自动化分界线：机械重复的 on call 调查(日志、指标)交给智能体，人类留给「为什么系统会这样」的深层推理。
• 让智能体学复盘有四条路：进训练集、语义搜索复盘库、写自己的记忆、把走过的步骤固化成工具(程序性记忆)。
• 别靠人盯智能体：人类是糟糕的监督者，系统越好越盯不住；用确定性的策略边界(如 Dogwood)把「什么算好」编码成围栏，来源一半组织、一半个人，且要随任务动态调整。
• 把功力花在规格和测试上：难的部分正从实现移向「写清你要什么 + 定义判定对错的标准」；测试现在是软件开发最前沿的部分。
• 用 AI 的分寸：当上下文提供者可以，当扩写器不行；文字背后是作者与读者之间的努力对称契约。
• 反馈信号从最笨的开始：agents.md + 测试门禁，再上共享的团队智能体 wiki 和组织级语义搜索，别一步跳到参数化记忆。

我们从几十年来对心理学、运营和操作员的研究中知道的一件事是：人类是非常糟糕的监督者。
Well, one of the things that we know from you know decades of research into psychology and operations and operators is that humans are really bad supervisors.
—— Marc Brooker · [25:20]

但我认为，通过观察真实系统如何失败——包括我们自己的和全行业的系统——并真正试图提取出「是什么把系统踢进了这种状态」，我们学到的东西多得多。
But I think we’ve learned a huge amount more by looking at how real systems fail, both you know, our own and systems across the industry, and really trying to extract like, what was it that kicked the system into this state?
—— Marc Brooker · [12:30]

智能体可以帮你深挖这些问题，帮你找到可能驱动客户那些感知的指标，但通常不太擅长真正理解这项工作的端到端上下文。
And so, you know, agents can help you dig into those and can help you find um uh find the uh the the metrics that might be driving those perceptions from customers or driving those anecdotes, um, but generally aren’t as good at really understanding the end-to-end context of the work.
—— Marc Brooker · [19:28]

我们的客户想要的，是一些能非常清晰、非常确定性地思考的方法：如何给智能体建一个盒子，说「我信任这个智能体做这件事、这件事和这件事，但它没有任何权限去做那些事」。
And what our customers are asking for is ways to think very clearly, very deterministically about how to build a box around agents and say, I’m gonna trust this agent to do this thing, this thing, and this thing, but it is not going to have any access to do you know these things.
—— Marc Brooker · [22:18]

所以我认为唯一的解决方案就是自主性，对吧？把人类从回路中拉出来，让他们不用看着回路转圈、在坏事发生时按下按钮。
And so I think the only solution to this is that autonomy, right? Pull the human out of the loop, make them not watch the loop go round and push the button when something bad happens.
—— Marc Brooker · [26:05]

但它本质上归结为这样一个想法：软件构建中难的部分，我要说是——规格构建。
Um but it essentially it comes down to this idea that the hard part of software building is um I’m gonna say specification building.
—— Marc Brooker · [32:43]

一旦你有了那个规格、把想要的东西写下来，我的信念是：我们会看到，这套软件可靠、高效实现的构建和维护，会随着时间推移变得完全自动化。
Once you have that specification, once you have that what you want written down, my belief is that we’re going to see the building and maintenance of reliable, efficient implementations of that software become over time entirely automated.
—— Marc Brooker · [33:14]

而且你知道，在某种意义上，测试现在是软件开发中最重要的部分。
Um and you know, in some sense uh testing uh is is now the most important part of software development.
—— Marc Brooker · [35:07]

我想要的是伟大的决策被做出——但是让伟大的决策被更自动地做出。
I I I want you know great decisions to be made, but great decisions to be made more automatically.
—— Marc Brooker · [39:34]

我认为这已经改变了，并且在整个行业迅速改变：随着人类从代码层退出、进入规约层，随着大量编码工作变得完全自动化，代码正越来越多地变成纯粹的实现载体，而不是沟通载体。
I think that’s changed and is very quickly changing across the industry as humans get out of that code level into more of that kind of specification level, as a lot of that coding becomes fully automated, is code is turning more and more into purely an implementation vehicle rather than a communication vehicle.
—— Marc Brooker · [40:56]

而如果我用 Claude 五分钟为我写一篇博客文章，然后假设一万人来读、每人各花 10 分钟读它，那么我投入的努力和读者投入的努力之间就存在巨大的不对称。我认为那是不公平的。
Whereas if I get Claude to write a blog post for me in you know five minutes, and then let’s say 10,000 people read it and they each take, you know, each spend 10 minutes reading it, there’s this huge asymmetry between the amount of effort that I’m putting in and the amount of effort that my readers are putting in. And I think that is unfair.
—— Marc Brooker · [41:50]

所以区别也许在于：如果你把 Claude 当扩写器用——「这是一个提示词，把它变成一份六页的文档」——我认为那是在浪费读者的时间；而如果你把 Claude 当上下文提供者用——比如「加一段本周业务指标」——我觉得那没问题。
And so maybe the distinction there is if you’re using Claude as an expander, right, saying, here’s a prompt, turn it into a six-page document, I think that’s a waste of the reader’s time. However, if you’re using Claude as a context provider, right, like add a paragraph with the business metrics for this week, I think that’s fine.
—— Marc Brooker · [45:09]

而且很多团队早期会试图直接跳到最后，说「哦，我要做参数化记忆之类的」——而其实「Clippy 满意并通过所有测试之前不许发布代码」就是一件非常有效、开销非常小的事情。
Um and I think a lot of teams early on try and jump to the end and say, oh, I’m gonna do parametric memory or something, when you know you can’t ship code until Clippy is happy with it and it passes all the tests, um, is a very effective thing with very little uh very little um overhead.
—— Marc Brooker · [47:53]

底线是：如果我们把梯子抽掉、让软件工程师这个群体变得越来越灰白，我们就不会有那种增长。
And and the bottom line is we’re we’re not going to do that growth, and we’re not gonna have that growth if we pull up the ladder and and you know the the community of software engineers just gets grayer and grayer.
—— Marc Brooker · [52:31]