工程师，开始给 Agent 打工了
正文
这篇文章讲的是OpenAI的三个工程师如何通过精心设计的Agent工作流，撬动了百万行代码的工程量。
核心观点
3个工程师能撬动100万行代码，重点不是"Agent把工程师替掉了"。真正发生的事情是，工程师的杠杆变了。
过去，工程师的产出更多取决于自己亲手写了多少。 现在，工程师的产出越来越取决于他能不能把Agent的执行环境设计好。
关键要素
清晰的AGENTS.md
- NOW.md看优先级
- MEMORY.md看长期积累
- content-playbook.md看内容策略
- Agent读AGENTS.md不是为了在这一页里理解全部事情，它要的是知道下一步该去哪里读，去哪里拿到完成任务真正需要的上下文
"Agent看不到的，等于不存在"
- 所有关键知识，都必须编码进repo
- 如果一个设计决策只存在于某条Slack消息里，或者只存在于某个工程师的脑子里，Agent就永远不会知道
- 对人来说，很多缺失的信息可以靠常识补，可以问同事，可以凭经验猜，可以从语境里推断
- 对Agent来说，它只能使用它看得到的东西
- 所以，一个能让Agent高效工作的repo，必须尽量接近一个完整、自解释、可追踪的系统
用linter机械化强制架构
- Agent生成代码的速度太快，人工review很容易跟不上
- 很多原来靠资深工程师肉眼发现的问题，到了agent-first的工作流里，已经不适合继续靠人力兜底
- 最好的办法，是把规范直接写进系统里
- 用linter、CI、自动检查去执行规范
- 凡是可以机械化的质量控制，都应该尽量机械化
- 人的注意力应该留给那些只有人能做判断的事情
垃圾回收是必须的
- Agent会复制repo里已有的模式。好的会复制，坏的也会复制
- 如果repo里有一个写得不好的函数，在过去，它可能只是一个局部问题
- Agent介入之后，它会参考这个函数继续生成类似实现
- 新生成的实现又会变成新的参考，然后坏模式开始扩散，这个过程会越来越快
- 所以他们专门做"垃圾回收"，定期清理repo里的坏模式
核心洞察
这意味着，未来最值钱的工程师，未必是写代码最快的人。更可能是最会把知识、约束和反馈，整理成Agent可执行环境的人。
这件事，已经开始发生了。
接下来真正该问的问题是：我有没有把我的知识、规范、流程和反馈，整理成一个Agent能持续工作的系统。
*注：以上内容为从原始推文文章中提取的核心观点和主要内容，保持了原文的论述结构和重要观点。*