https://x.com/thorstenball/status/2114386050638336082 讲讲这个

回复 群友 1384 这是 Thorsten Ball（Amp 的工程师，《Writing an Interpreter in Go》作者）10 月 25 日发的一篇《How I work with Agents》，写明是 2026 年 10 月的现状。全篇是他一系列工作习惯，讲法很直接。 核心几条： 用最新最强的模型，其他都是浪费时间。他的推理：一个错误率 10% 的模型，你不知道错在哪 10%，结果就是反复重试。所以别为便宜一半但随机笨 20% 的通用模型省那点钱。 别怕累积 slop。代码库被搞成一团乱麻这个担忧，他觉得半年前可能成立，现在不一定，而且就算有 slop 也不一定不可维护。 提示 What 而不是 How。描述你想要的结果，别描述你打算怎么做。他给的例子是“把字节码编译器和虚拟机做到你能做到的最快，不做完不停，目标是 2 倍性能”。 让整个 SDLC 对 agent 可见。他的判断很到位：真正压住幻觉的是工具调用，因为工具让它能接触到现实。agent 看不到的东西它就编。所以让它跑自己写的东西、读生产日志、部署、盯 rollout、发版、开开关、分派 bug report、给客户发邮件：你能看到的，它都该看到。配套还得给它 SDLC 的工具：bug 上报、给用户发邮件、“系统健康吗”、开 feature flag，他们在 Amp 都写成了自定义插件。 评测 agent 的知识沉淀。AGENTS.md、skills、脚本、文档越堆越多，那 agent 到底用不用？办法是开五个盲跑的 agent 做对照实验，看控制组和实验组的差别。他的观察是 agent 做这种实验特别擅长。 本地开发现在很别扭。每个 agent 应该能自己装、自己跑它需要的东西，远程机器上很好办，本地就难受，端到端测起来资源冲突躲不掉。这条其实是在说为什么要用远程沙箱。 别跟 agent 一步步迭代，让它自己造工具来迭代。不是“试试这个……不行，换那个”，而是“生成 20 个变体，再给我一个页面让我组合着测”。这个思路也能用到问题空间上：“给我 4 个它慢的原因假设，然后逐个验证”。 要不可辩驳的证据。他认为这是最大的变化点：agent 很擅长产出证据，端到端走查、demo 视频、前后对比数字。同时要在 AGENTS.md 里写清楚“这不算证据”，把信任和判断力养出来。 别等 agent，让它等你。他说如果你还在担心 TTFT，大概是方向错了。往异步上押，派更大的活，一次批处理而不是来回拉扯。 自动化、定时、唤醒、心跳是杀手级功能。他关了才发现离不开：“两小时后看下日志”“上线了告诉我”“每天早上 9 点检查一下”。 别手动管 context。花心思琢磨“它现在用了 300k 还是 380k token”是纯浪费，compaction 已经很好用。一个 thread 一件事，有的 thread 46 条消息，有的 3714 条。 thread 就是公司的记忆。在 Amp 里问“我们当时为什么这么做”，团队用得越多知识越多，而且 thread 挂在 git commit 上，能避免重复劳动。 别让 agent 写给人看的东西。除了调试步骤、事故报告、部分文档这类机械活。 只审高风险半径的代码。中心文件不到 5 个，他看；数据库迁移，看。闭包还是类、类型写得漂不漂亮、变量名、甚至重复，他都不管了。只看：能跑吗，箭头级别的架构我懂吗，agent 端到端测过吗，一个月后我还改得动吗——都行才可能去看代码。 我的看法：这篇最有价值的是“别迭代，让它造迭代工具”和“要不可辩驳的证据”这两条，它们把 agent 从对话对象变成了并行生产者；剩下几条本质上是同一个立场，把人从编译器的微操里撤出来，只保留架构判断和风险审查。跟前面那篇 Anthropic 讲折叠 subagent 的思路其实互补：一个讲结构该简单，一个讲个人工作流该异步和批量化。