最近发现了 Armin Ronacher 的一个演讲，受益良多，在此记录下来，便于日后复习参考。
Armin Ronacher 是 Python 社区和 Coding Agent 社区的标志性人物，创造了 Flask（Web 微框架）、Jinja2（模板引擎）、Rye（Python 包管理工具）等核心项目，参与维护极简编码智能体 Pi Coding Agent。在离开 Sentry（错误监控公司）后，全身心投入到 Agentic 编程（AI 智能体编程）领域。这场演讲就是他前期探索的系统性总结。演讲录制于 2026 年 3 月，旧金山 PyAI 大会。
核心问题：基础模型的黑盒困境
We are all somewhat beholden to foundation model providers. That means we have to learn from behavior, not from internals.
Armin 首先抛出了一个根本性问题：基础模型（foundation models）是一个黑盒。我们无法窥探它的内部结构，不知道它是如何训练的，不清楚模型针对哪些方面做了优化，也不知道它具体学到了什么、是怎么推理的。那么，当模型不断迭代更新时，如何构建一个不会因模型升级而频繁崩溃的 Agent？
关键洞察：强化学习的训练数据决定了模型的未来能力
以下是演讲的核心内容。
2.1 强化学习让模型具有“Agent 能力”
基础大模型本身并不具备真正的“Agent 能力”，但通过在大量会话数据（session data）上做强化学习训练，模型才能像 Agent 一样使用工具、规划任务、调用 API 等。
2.2 会话数据从哪里来？
来自编程 Agent 的实际使用。如 Claude Code、Cursor 等工具产生的编程会话，用户给出任务，Agent 执行操作（读写文件、运行命令、查看 diff），最终产生结果。这些会话是可测量、可评估的：任务成功与否，代码能否跑通？
2.3 正反馈循环
编程 Agent 被大量使用 => 产生海量会话数据 => 喂给强化学习训练 => 训练后模型在常见模式上越来越强 => Agent 在这些模式（任务）上表现更好 => 产生更高质量会话数据...
核心结论：编程 Agent 当前经常使用的技术和工具，就是未来模型会持续强化、持续变好的方向。反过来，那些 Agent 很少碰到的东西，模型在可预见的未来也难以变得擅长。
顺势而为：Agent 擅长什么
基于上述正反馈循环，Armin 列出了 Agent 目前擅长并且会持续变强的领域：
- Unix 文件系统操作：读写文件、遍历目录。这是几乎所有编程 Agent 的基本操作，模型在这方面训练数据极其丰富。
- Bash 命令行：执行命令、管道操作、脚本编写。这是编程 Agent 最常用的接口之一。
- 流行的语言和构建工具：如 SQL（最流行的关系型数据库查询语言）、TypeScript。
- 增量式修改：查看文件当前状态，做出精确修改。
- 权限系统、测试、日志以及堆栈跟踪。
启示：构建 Agent 系统时，应该优先选择这些技术栈作为 Agent 与外界交互的接口。因为模型在这些方面已经很强，而且会越来越强。
逆风而行：Agent 不擅长的东西
模型在某些方面表现不佳，而且短期内不会有根本性改善：
- GUI 交互：点击按钮、填写表单、操作图形界面。模型训练数据中这种操作极少，而且 UI 操作很难用文本精确描述。
- 专有系统：私有 API、内部工具、非公开协议。这些不在公开训练数据中。
- 二进制数据：图片、视频、音频、二进制文件。这些无法简单地分解为文本。
- 任何无法干净地分解为文本的东西。
不过，编程 Agent 正越来越多地使用屏幕截图，意味着编码上下文的视觉理解代表了编码 Agent 的下一个方向。与此同时，编码相关的工具正成为工作空间自动化的基础，越来越多的应用基于编码 Agent 构建。
实践建议
5.1 隐藏状态变化问题（The hidden state change problem）
问题描述：Agent 在执行过程中，外部世界的状态发生了变化，但 Agent 未及时感知。如果仍然基于过时的认知继续操作，无疑将导致错误。
问题原因：Agent 没有持续感知外部世界变化的机制，它的“世界观”是在某个时间点建立的快照（瞬时状态）。
应对策略：尽量减少 Agent 依赖外部状态，或者设计系统让状态变化是可检测的。
两个示例：
- 编码智能体如何及时感知当前目录和正在操作的文件？做法是：在每次会话和操作前，向模型提供当前的 PWD 与操作路径，让模型时刻知道自己在哪里、在操作哪个文件。
- 浏览器智能体如何及时感知所在网页的 URL？通过 URL 感知用户是否切换了页面，进而读取页面内容，更好地服务用户。
5.2 构建 Agent 的指导建议
综合此前的分析，Armin 给出了一些建议：
- 顺着模型训练数据的方向走，用文件系统、Bash、SQL 这些已被充分训练的模式。
- 基于可观察行为推断，而不是猜测模型内部机制。
- 围绕密集文本反馈的工作流构建。
- 不要只为模型现在的能力做优化，而是面向未来设计：今天做的决策，要确保在下一代模型出来时依然成立。
5.3 上下文效率
不要把大量信息一股脑灌进 Agent 的上下文窗口。上下文窗口虽然越来越大，但塞太多信息会降低模型的推理质量（注意力稀释）。更好的做法是：
- 用文件作为信息载体，Agent 需要时自己去读。
- 用 grep / search 来定位信息，不是把整个文件内容放进上下文。
- 按需加载，只在需要时才把相关信息引入上下文。
这和人类工作的方式类似：你不会把整个代码库打印出来铺在桌上，而是用到哪个文件就打开哪个。
5.4 微型可编程世界：沙盒执行
提供一个安全、可控的执行环境，如 Monty，让 Agent 可以在里面运行 Python 代码，而且不会对宿主系统造成影响。
5.5 SQL 优于自定义 DSL
SQL 是训练数据中最丰富的查询语言，模型对 SQL 的理解极其深入，而且模型在未来会持续在 SQL 上变强（因为 SQL 在编程 Agent 会话中无处不在）。相比之下，自定义 DSL（领域特定语言）对模型来说是陌生的，它需要额外学习，且容易出错。
5.6 测试假设：问模型会怎么解决
Armin 给出了一个简单的了解模型的方法：在构建 Agent 之前，先把问题抛给模型，问它会怎么解决这个问题。模型给出的方案会反映它在训练数据中最熟悉的解决路径。如果设计跟模型自然倾向的方式一致，成功的概率就更高。如果模型给出的方案和预想的完全不同，则可能需要重新考虑设计。
5.7 使用自己的会话数据
自己与模型交互的会话记录（session traces）可以作为 Agent 的输入数据，这些数据对于评估智能体非常重要，可以用来减少工具使用、简化框架和提示词。
总结：顺着纹理切割
Build with the grain, extrapolate forward.
即不要逆着模型的训练数据方向构建，找到模型已经擅长的事情，把你的系统设计在这个基础上。另外，不要只看今天模型能做什么，要看趋势。强化学习的正反馈循环意味着，今天稍微强的方向，明天会更强。