AI 写代码到底能不能用于真正的生产？最近OpenAI 内部的实验给出了答案：不是"能不能用"，而是你愿不愿意重新设计整个工作流来配合它。
最近，OpenAI Frontier 团队Ryan Lopopolo 的一个关于 “Harness Engineering” 的帖子在硅谷火了。OpenAI 的 Frontier 团队在 5 个月内搞出了一个拥有 100 万行代码的代码库，但里面的代码没有一行是人写的，甚至在合并之前，连人工审查都没有。 Ryan 甚至说如果你每天不消耗掉 10 亿个 Token，在 AI 时代你简直就是在“玩忽职守”。在这五个月里，他们采用了一种不同的工程工作模式：当Agent出现故障时，团队不会简单地提示它更好一些或让它“更加努力”，而是会去探究“缺少哪些能力、上下文或结构？”，最终成果是他们构建了一个叫 Symphony 的系统。它不分发具体代码，而是分发“规范”。
Ryan Lopopolo近期也接受了Latent Space播客的访谈，在这次对话中他详细复盘了他在过去五个月进行的这场实验，深入探讨了Symphony编排架构、每日消耗 10 亿 Token 的生产逻辑以及企业级 Agent 的受控部署等话题。
Ryan Lopopolo 指出，在 GPT-5.4 等具备深度推理与视觉感知能力的模型驱动下，代码已从需要精密维护的长期资产转变为低成本的瞬时耗材。他认为，当代码编写成本趋近于零，针对质量不佳或架构演进的代码，最廉价的处理方式是直接丢弃并由模型重产出，而非进行人工重构。
在 Agent 产出效率达到人类十倍以上的背景下，传统的合并前代码审查模式已无法承载高频迭代。Harness 工程的核心逻辑在于“环境重于指令”。当 Agent 任务失败时，团队不再纠结于如何优化提示词，而是去反思系统缺失了何种能力、上下文或结构。他主张将整个代码库、工作流甚至组织架构，按照“Agent 易读性”而非“人类习惯”进行彻底重构。
他预测，未来的软件工程将进入“免人工审查”时代。通过将工程师的架构品味、安全护栏和可观测性工具编码进 Harness 系统，Agent 可以在完全受控的环境下自主完成从开发到运维的全链路工作。
01
通过构建受控 AI Agent 平台将模型转化为企业级解决方案
由于你在Snowflake、Databricks、Stripe 和Citadel等顶级企业服务公司拥有深厚的背景，这种传统大型企业端经验与你现在表现出的“全速推进 AI”的极大主义者心态结合得非常有意思。请向大家介绍一下你目前在 OpenAI 负责的团队，以及这项研究工作的初衷是什么？
Ryan Lopopolo:我目前从事前沿产品探索，在OpenAI Frontier 部门负责新产品开发。这是一个企业级平台，旨在帮助任何企业安全、大规模地部署受控的 AI Agent。我团队的任务是探索如何将我们的模型转化为可直接销售给企业客户的封装产品和解决方案。这些公司都有一个共同点，那就是服务于各种类型的客户，而且正是你们现在想要争取的那类客户。如果你想扮演 AI 极大主义者的角色，OpenAI 确实是最佳选择。而且我们在内部没有任何速率限制，这对我全速推进现阶段的研究大有帮助。我们获得了一些自由探索的空间，这非常令人兴奋。
你们在开发一个内部工具的五个月里没写一行代码，最终产出了超过一百万行代码，这比手动开发快了十倍。请详细聊聊设定这种“不写代码”极端约束背后的逻辑。
Ryan Lopopolo:我尝试了一个比较极端的约束，那就是不亲手写任何代码。我想，如果我们想开发能部署到企业的AI Agent，它们就应该能胜任我所做的一切工作。在与这些编码模型和 Harness 合作了半年多以后，我深感模型和 Harness 的能力已经足够成熟，足以在工作能力上与我平分秋色。设定不写代码的约束，意味着我完成工作的唯一途径就是通过 AI Agent 来实现。
（关于起初的困难）起初我们使用的是 Codex CLI 的早期版本，搭载的是 Codex Mini 模型，其能力远逊于现在的模型。但这其实是一个非常好的约束。当你要求模型构建一个产品功能，而它却无法将各个组件组装在一起时，那种无力感是非常深刻的。这定义了我们后来的一项核心准则：每当模型卡壳时不要强推，而是深入拆解任务，构建更小的模块化组件，再重新组合以实现更大的目标。
初期非常痛苦，前一个半月的工作效率比我亲自上手慢了十倍。但正是因为付出了这个代价，我们最终构建出了一个供 AI Agent 操作的自动化组装站，这让后期的产出远超任何单一工程师。
02
通过强制性的一分钟构建纪律，确保 AI Agent 在多代模型演进中的生产力不变性
从GPT-5 到 5.4 的代际演进中，模型的工作习惯发生了哪些变化？你们为何从 Makefile 转向 Bazel、Turbo 和 NX，并死磕“一分钟构建反馈”这个硬指标？如果超时了系统会如何处理？此外，后台 Shell 的引入对调用效率有何实质提升？
Ryan Lopopolo: 接着，我们经历了GPT-5、5.1 到 5.4 的多代模型演进。不同代际的模型有各自的特点和工作习惯，这意味着每当模型升级，我们都要调整代码库。在 5.2 版本时，Codex Harness 还没有后台 Shell 功能，我们只能依赖阻塞脚本来处理长跨度任务。到了 5.3 版本，有了后台 Shell，模型变得没那么有耐心了，不再愿意等待阻塞操作。于是我们被迫重构了整个构建系统，确保所有任务都能在一分钟内完成。在人类工程师主导、各执己见的代码库里，这种重构几乎不可能完成。但由于我们的唯一目标是提升 AI Agent 在一周内的生产力，我们迅速从传统的 Makefile 转向了 Bazel，接着是 Turbo 和 NX。当构建速度达标后，我们就固定在了这个方案上。
（关于技术选型细节）其实我对前端仓库架构并没有太深的执念。我们唯一追求的目标就是快。目前的架构主要是基于 Electron 的单体应用。我们需要内环反馈尽可能快。一分钟只是一个设定的硬指标，而我们做到了。如果超时了，系统不会自动强杀，但超时是一个信号，告诉我们需要停下来，对构建图进行进一步拆解，优化性能，从而让 AI Agent 能够继续高效地工作。我以前在平台团队的经验是，大家对构建时间有一个容忍区间，通常会任由它增长直到触及红线，才花几周时间去优化。你提到你现在的项目构建要 12 分钟，那确实很折磨人。但因为 Token 极其廉价，而且我们与模型的并行效率极高，我们可以持续不断地修剪系统以维持性能不变性。这意味着代码和 SDLC 流程的离散度更低，我们可以大幅简化逻辑，并依赖更多确定的约束来编写软件。
（关于后台 Shell 功能）简单来说，Codex 现在可以在后台启动命令，并在等待执行结果的同时继续做其他工作。比如它可以在启动一个耗时较长的构建任务时，同步进行代码审查。这大大提升了用户调用 Harness 时的效率。
03
如何让Agent 掌控全局
在三个人的团队产出百万行代码和1500 个 PR 的情况下，你们是如何定义系统高层逻辑并进行 PR 审查的？当人类成为瓶颈，这一流程发生了怎样的改变？如果把每个决策都变成永久的全局规则，遇到特例需要回滚时该如何处理？
Ryan Lopopolo:实际上，我们已经跨越了由人类审查代码的阶段。目前大部分人工审查都是在合并后进行的。
swyx：那甚至不能叫审查了，只能叫求个心安。
Ryan Lopopolo:从根本上说，模型是可以无限扩展的。只要我投入足够的GPU 和 Token，我就能获得海量的代码处理能力。真正稀缺的资源是我团队成员的注意力。一天只有 24 小时，我们需要吃饭睡觉。你必须学会抽身，以系统性思维去观察，AI Agent 在哪里犯错，我把时间花在哪了，如何实现进一步的自动化。当我们对自动化流程建立信心后，这一环节的 SDLC 问题就迎刃而解了。最初我们需要紧盯代码，是因为 AI Agent 当时缺乏构建模块化、可靠且可观测性软件所需的积木。
swyx：这些经验会反馈给根编码 AI Agent。你也可以基于此训练一个专门的代码审查 AI Agent，让它根据这些沉淀的知识来收束代码生成的边界。但我担心的是，如果你把每个决策都变成永久的全局规则，万一遇到需要特例处理的情况，回滚起来会很麻烦。
Ryan Lopopolo:我们在提示词里明确允许AI Agent 进行质疑。
为了不把时间耗在终端前，你们构建了怎样的可观测性系统？这种让Codex 作为唯一入口、掌控全局并利用 SPEC.md 和 AGENT.md 进行引导的做法，与旧版模型相比有何根本区别？如何将偶发的 Bug 修复沉淀为永久的工程经验？
Ryan Lopopolo: 为了不把时间耗在终端前死磕一两件事，我们投资构建了可观测性系统。最开始只有一个基础应用，剩下的部分，从向量数据库到各类指标监控API，我只用了半个下午就搞定了。我们特意选择了一些高效、成熟的开发工具。比如我们大量使用 me 来快速拉取 Go 编写的 Victoria Stack 二进制文件，再用一点 Python 胶水代码把它们运行起来。这里有一个关键的思路转换，以往是先搭环境再跑 AI Agent，而我们把编码 AI Agent 即 Codex 作为唯一的入口点。我们通过技能和脚本赋予 Codex 启动整个技术栈的能力。Codex 自行决定何时启动环境、如何设置变量。这种让 Harness 掌控全局的做法是推理模型与旧版模型的根本区别。旧模型由于缺乏思考能力，必须被限制在预设状态机里，而现在我们直接给模型一个全能盒子和足够的上下文，让它自主做出智能决策。
（关于脚手架与文档引导）这种结构让向仓库添加引导信息变得非常低成本，无论是引导人类还是 AI Agent。我们开始做的时候，现在的这些技能概念还没出现。技术追踪器和质量评分非常有趣，这本质上是一个微型脚手架，作为 Codex 的钩子来审查业务逻辑，评估代码是否符合预设的护栏，并为自己规划后续工作。在引入复杂的票据系统之前，我们只用 Markdown 记笔记来跟踪后续任务，并启动一个 AI Agent 来处理。
（关于经验的永久沉淀）模型天生渴求文本。因此，我们核心的工作就是寻找向系统中注入文本的方法。比如当由于缺少超时设置而导致页面崩溃时，我直接在 Slack 里艾特 Codex 告诉它，我要加个超时来修这个 Bug，请同步更新我们的可靠性文档，要求所有网络请求必须包含超时设置。这样我不但修好了当前的 Bug，还把这个工程经验永久地沉淀成了系统流程。
04
Agent 代码审查规则与灵活性
你们如何平衡代码审查代理与编写代理之间的关系，避免它们陷入无意义的争论？在给予代理自主合并权限时，你们如何设置安全防线，特别是考虑到这是要交付给客户的生产级产品，是否有类似“紧急制动”的机制来确保可靠性？
Ryan Lopopolo:刚开始引入代码审查AI Agent 时，Codex CLI 在本地修改代码并提交 PR，触发审查 AI Agent 发表评论。我们要求 Codex 必须回应这些反馈。结果发现，负责写代码的 Codex 经常被审查 AI Agent 霸凌，导致双方陷入无意义的争论，无法达成共识。所以我们必须在提示词里增加灵活性。我们指示审查 AI Agent 优先倾向于准予合并，且不要提出任何优先级高于 P2 的问题。
（关于评分框架）我们给了一个评分框架。P0 代表如果合并了，代码库就会崩溃。在代码编写 AI Agent 这一端，我们也赋予了它灵活性，让它可以推迟甚至拒绝评审反馈。这种情况在现实中很常见，比如我随手提了一个代码评审建议，但这可能会让原本的任务范围扩大一倍。我通常并不要求它立刻解决，更多是打个招呼，建议把它放进待办事项，等下次集中修复周再处理。如果 AI Agent 没有这样做是被允许的背景信息，它们往往会陷入盲目执行指令的模式。
（关于合并安全）这里的关键在于我们构建的是原生应用程序，并没有采用持续部署。因此在切分发布分支时，仍然需要人类参与。在正式发布之前，我们需要经过授权的人类对应用进行冒烟测试，这是一道必经的关卡。我们是在开发应用，而不是那种对可靠性有极高要求的底层基础设施。当然，所有这些实验都是在一个全新的仓库中进行的，并没有适用于所有场景的通用脚本。但这毕竟是要交付给客户的生产级产品，所以这是实打实的生产实践。
05
GPT-5.4 驱动的自动化闭环
随着GPT-5.4 这种整合了顶级编码、通用推理与视觉能力的模型出现，目前人类的参与程度具体是多少？在自动化运维方面，它是如何利用全局信息处理仪表盘定义与告警传呼的？
Ryan Lopopolo:那个模型（GPT-5.4）确实非常惊人。有了 5.4 版本，我可以直接让 Codex 帮我写博客文章了，而以前我必须在不同的对话框之间反复权衡和调整。这种自动化闭环随处可见。比如刚才提到的仪表盘，我们让 Codex 编写 Grafana 仪表盘的 JSON 定义并直接发布。它还会响应告警传呼，这意味着当它收到告警时，它确切地知道对应的仪表盘定义和报警阈值，甚至能精准定位是代码库中哪一行日志触发了告警，因为所有这些信息都被整合在了一起。
（关于全局信息）没错。这意味着如果发生了没有触发自动报警的故障，它也可以利用现有的仪表盘、指标和日志，分析出监控缺口并一次性修复。这就像一个全栈工程师，能够独立负责从后端逻辑到前端呈现的整个功能特性。
06
代理可读性与架构约束
顺应模型的“天性”编写软件是否会牺牲人类可读性？对于这种通过强制执行架构边界来设定“品味”的做法，你作为技术负责人的心态发生了怎样的转变？这种基于 Model-View-Claw（Harness）的架构又是如何定义的？
Ryan Lopopolo: 我的心态已经转变为从具体流程中抽离出来。我不再对代码细节指手画脚，这种感觉就像是一个管理500 人组织的技术负责人。我不可能深挖每一个拉取请求的细节，所以提交后代码评审是一个很好的类比，我只需观察一部分代码样本，就能推断出团队在哪些方面遇到了挑战。所以我对代码的具体写法并没有太多执念。
（关于架构原语的执行）不过，我确实提供了一个基于命令的基类，用于实现可复用的业务逻辑块。它自带了链路追踪、指标监控和可观测性。重点不在于业务逻辑怎么写，而在于必须使用这个原语，因为我知道这能提供默认的杠杆效应。随着模型能力的增强，它们更擅长自己提出抽象方案来解决障碍。这让我能站在更高的维度，去思考未来究竟是什么在阻碍团队的交付。我们确实有云端后端。这种架构实际上存在于 Electron 独立的主进程和渲染进程之间，我们也以同样的严谨度处理了 MVC 风格的代码拆分。
（关于 Model-View-Claw 构想）利用 Codex 和 Harness 构建 AI 产品是一个非常值得探索的领域。如果你能将产品愿景或用户旅程转化为代码逻辑，那么使用 Codex Harness 来实现它就顺理成章了。它负责所有的底层连线，你只需要通过提示词告诉模型你的意图，让它去自由发挥就好。编程代理将会吞噬那些通常被认为是非编程的知识工作。与其单独构建一个代理，不如从编码代理开始向外扩展。
07
如何看待“软件依赖正在消失”
你如何看待“软件依赖正在消失”的观点？如果通过直接内联代码来取代第三方库，如何确保代码的信心，以及如何利用 AI 进行深度安全审查？
Ryan Lopopolo:百分之百同意软件依赖正在消失。目前我们能内部化的依赖复杂度还处于中低水平，大约几千行代码的依赖，我们一个下午就能完成内部化。最妙的是，你通常不需要那个依赖库的所有功能，通过内部化，你可以剥离掉所有冗余代码。此外，当我们在仓库中部署Codex Security 时，它可以深度审查这些内部化的代码。这比向游提交补丁、等发布要高效得多。如果代码编写是免费的，内部化的摩擦力就会降到最低。
（关于信心建立）内部化意味着你得重新建立对代码的信心。就像我说的，现在连内部工具都是 Codex 为自己编写的。我们在内部向首批十几位用户部署了应用，结果出现了一些性能问题。于是我们让他们导出追踪文件并打包，交给了我们的值班工程师。他利用 Codex 构建了一个精美的本地开发者关系工具，这是一个 Next.js 应用。你只需把压缩包拖进去，它就能可视化整个追踪路径。
（关于调试逻辑）这确实很棒，虽然花了一个下午，但其实没必要。因为你完全可以直接启动 Codex，把包丢给它并询问同样的问题，瞬间就能得到答复。所以从某种程度上说，优化调试过程的人类可读性反而是错的。这让工程师不必要地留在闭环中，而他原本可以让 Codex 跑五分钟，得到同样的结果。在本地可观测性栈中，你当然可以部署 Jaeger 来可视化追踪，但我压根儿不指望去盯着看，因为我不打算亲自动手写代码去修复它们。
08
Ghost Libraries 规范与软件分发的新形态
推特上的人们管这种将软件作为规范进行分发的模式叫“Ghost Libraries”，这个名字非常酷。这种流程是如何让向世界分享软件的成本变得极低的，你们具体是如何通过 Codex 实例和 tmux 窗口实现规范的循环验证与高保真复现的？
Ryan Lopopolo:这个名字非常酷，这意味着向世界分享软件的成本变得极低。你只需要定义一个规范，说明如何构建它，并提供足够的信息，让编码AI Agent 在本地重新组装。这个流程非常酷，我们提取了私有仓库中所有的脚手架，启动一个新仓库。然后询问以该仓库为参考的 Codex，让它编写规范。接着启动一个 tmux 窗口，运行一个独立的 Codex 实例来实现这个规范。等它完成后，再启动另一个 Codex 实例和 tmux 窗口，将实现结果与上游进行对比审查并更新规范，以缩小差异。就这样按照 Ralph 风格不断循环，直到得到一个能高保真复现现有系统的规范。这体验太棒了。
（关于人类偏见）没错，很多时候人们写规范会觉得我应该这样做，然后反复推敲，其实没必要，AI Agent 完全能处理。你现在依然在某种意义上搭建脚手架，但 AI Agent 能更好地确定规范细节。我认为对于困难且新颖的事物，模型仍然需要人类来驱动，但其他象限基本都解决了，只要有合适的脚手架和驱动 AI Agent 完成任务的机制。这能解决掉那些确实很不可思议，但这意味着人类这种时间和注意力有限的资源，可以专注于最难的部分。比如那些完全空白的领域，或者最深层的重构，即你还不清楚接口的最佳形状。这才是我想花时间的地方，因为它能让我为下一个量级的 Scaling law 做好准备。
09
如何为每个 AI 任务提供原生的监控与编排支持
你们推出的Symphony 系统选择了 Elixir 这种相对小众的语言，这在技术选型上非常有意思。Elixir 的进程监督和 GenServer 机制是如何与你们正在做的 AI 进程编排相契合的，你们用它具体解决什么问题？
Ryan Lopopolo:没错。它之所以选Elixir，是因为其进程监督和 GenServer 机制非常契合我们正在做的进程编排。你本质上是为每个执行中的任务启动微型守护进程并驱动其完成。这意味着通过使用 Elixir 和 BEAM 虚拟机，模型免费获得了大量底层功能。
（关于系统起源）12 月底时，我们每位工程师每天提交约 3.5 个 PR。那是 1 月初 5.2 模型发布前的事。休假回来后，大家用上了 5.2，在仓库里没有增加人手的情况下，每人每天的 PR 产量飙升到了 5 到 10 个。不断进行上下文切换非常累人，每天结束我都精疲力竭。这就引出了那个问题：人类的时间到底花在哪了？大家的时间都耗在各种活跃的 tmux 窗口之间切换，去驱动 AI Agent。所以我们要构建一些东西把自己从循环中解放出来。这也是我们在 Adapt 疯狂冲刺的原因，寻找一种方法，让工程师不必整天守在终端前。
10
免终端编排：将人类移出闭环
从5.2 模型发布后，你们团队的 PR 产出发生了怎样的量级变化？为了解决人类的时间瓶颈，Symphony 的“重做”状态是如何运作的，它如何让工程师在“零投入”编写过程的情况下实现对系统的反思？
Ryan Lopopolo: 12 月底时，我们每位工程师每天提交约 3.5 个 PR。那是 1 月初 5.2 模型发布前的事。休假回来后，大家用上了 5.2，在仓库里没有增加人手的情况下，每人每天的 PR 产量飙升到了 5 到 10 个。不断进行上下文切换非常累人，每天结束我都精疲力竭。这就引出了那个问题：人类的时间到底花在哪了？大家的时间都耗在各种活跃的 tmux 窗口之间切换，去驱动 AI Agent。所以我们要构建一些东西把自己从循环中解放出来。这也是我们在 Adapt 疯狂冲刺的原因，寻找一种方法，让工程师不必整天守在终端前。
（关于理想工作终态）我们实验了很多开发者关系工具箱和自动启动 AI Agent 的方案。理想的终态是，我悠闲地待在海滩上，每天只需要打开 Live 应用两次，对各项任务点个是或否。这是一种非常有意思的工作模式构想。因为我对延迟不再敏感，对代码本身也不再有那种作者荣誉感。我对实际的编写过程几乎零投入，所以如果是垃圾代码，我直接扔掉也不心疼。在 Symphony 中有一种重做状态，当 PR 提交给人类审查时，这应该是一个很轻松的过程，要么合并，要么重做。如果是后者，Elixir 服务会直接废弃整个工作树和 PR，从头开始。这又是一个反思的机会：为什么之前产出的是垃圾？ AI Agent 哪里做错了？在把任务移回进行中之前，先修好这些。
11
超前探索与“万名工程师架构”
为什么这些功能没有直接实现在Codex 的官方应用里？单人操作多智能体尚可应付，但多人协作多智能体简直是复杂度的爆炸。你提到的“万名工程师架构”具体指什么，为什么要给一个 7 人团队配置拥有 500 个 NPM 包的冗余架构？
Ryan Lopopolo:我们团队的风格是深度拥抱AI 并进行超前探索。我们研究的许多成果最终都整合进了公司的各类产品中。比如我们曾深入咨询 Codex 团队，促成了 Codex 应用的诞生，并推动了技能系统的实现，从而让我们不必亲自动手编写自动化代码。这种不受产品开发进度束缚的模式，让我们能快速试错并找出有效方案，再将其转化为可广泛部署的规模化产品。这种运作方式虽然带有一定的混沌感，由于没有直接参与开发循环，我经常忘记代码的实时状态。
（关于协作架构）单人操作多智能体尚可应付，多人协作多智能体简直是复杂度的爆炸。这就是为什么我们在应用中采用了极其严格的、万名工程师级别的架构，因为必须分割空间防止互相干扰。我们的仓库结构包含约 500 个 NPM 包。对于一个 7 人团队来说，这种架构极其过度。但如果每个人的产出相当于 10 到 50 人的规模，那么这种深度分解、分片和严格的接口边界就非常合理了。这让我想起了微前端。关于编排这么多工作流，你还有什么灵光一闪的时刻吗？
12
通过代码与流程的极致标准化降低 Agent 处理摩擦
在演示视频中，你们将Linear 和 Slack 与工作流进行了深度集成。既然你们对产品走向有影响力，除了目前关注的领域，你们认为开发者还应该构建哪些工具？是针对特定团队的小众工具，还是通用工具？此外，如何通过标准化代码和流程来提升 Agent 的处理效率？
Ryan Lopopolo:我们的使命是让AI Agent 从事有经济价值的工作。要实现 AI 的广泛部署，就必须找到它们与人类自然协作的方式，因此协作工具是一个非常值得探索的空间。这也取决于具体情况，但我认为核心杠杆在于让代码和流程尽可能标准化。如果代码即上下文，代码即提示词，那么从 AI Agent 行为的角度来看，不同目录下的包结构、语言和模式越统一，处理效率就越高。
（关于标准化技能）同样的道理也适用于技能。我们将所有工程师的经验倾注进一套核心技能中。目前我们的代码库中只有大约 6 个技能。如果开发循环中有覆盖不到的地方，我们会优先尝试将其编码进现有技能中。改变 AI Agent 的行为比改变人类的操作习惯要廉价得多。
13
AI Agent的自我优化机制
你们实验过让AI Agent 改变自己的行为吗？比如通过父智能体修改子智能体，或者通过分析会话日志来实现“内省”？Symphony 提到的六个反思提取层级（政策、配置、协调等）是如何运作的，系统能否实现某种形式的“自我修改”？
Ryan Lopopolo:实验过。比如通过父智能体修改子智能体的行为。我们在做技能蒸馏。Codex 有个很酷的用法：让它分析自己的会话日志，指导用户如何更好地使用工具。这就是内省。我们内部有个概念叫“万事皆可 Codex”。我们现在会将整个团队的日志收集到对象存储中，每天运行 AI Agent 循环进行分析，找出团队可以改进的地方并反馈到仓库中。这样每个人都能免费从他人的经验中受益。合并请求评论也是如此，无论是评论还是构建失败，这些都是信号，说明 AI Agent 在某个时刻缺少上下文。我们要做的就是吸收这些信号并回馈给系统。
（关于自我完善）这个系统甚至能自行创建工单，因为我们赋予了它完全的访问权限。你甚至可以在它提交的任务里，预设它下一步该创建什么样的工单。这就实现了自我修改。
14
命令行优先与 AI Agent 对UI 的视觉感知
在AI 浪潮下，我们看到软件正从图形界面向命令行（CLI）演变。你们如何减少对云端的依赖并在本地形成闭环？另外，对于 AI Agent 难以感知的 UI 布局，你们是如何通过“栅格化为 ASCII”这种奇特的方式来提升模型感知精度的？
Ryan Lopopolo:不要限制AI Agent 的发挥。要赋予它在其领域内的完整访问权限。没错，就是上下文和工具。作为开发者，我们习惯于调用各种外部系统，但在这里你使用的是 Prometheus 之类的开源工具，并且是在本地运行，从而形成完整的闭环。此外，还要尽量减少对云端的依赖。命令行界面之所以好用，是因为它们的 Token 效率极高，而且很容易进一步优化。
（关于 UI 感知）我们也一直在尝试将非文本内容转化成文本形式，以此优化模型的行为。我们希望 AI Agent 能看懂 UI。但它们并不像人类那样以视觉方式感知，它们看到的不是一个红色的框，而是“红色框按钮”这种描述，它们是在潜空间中感知这些事物的。如果我们想让它真正理解布局，最简单的方法其实是将图像栅格化为 ASCII 字符流，然后喂给 AI Agent。当然，也可以双管齐下，进一步提升模型对操作对象的感知精度。
在Symphony 的协作层实现中，Elixir 的运行时原语如何帮助模型找到“捷径”？此外，为了建立对 Agent 产出代码的信任，你们为什么坚持在合并请求时附带 Agent 自动生成的录屏视频？
Ryan Lopopolo:这里的协作层是实现过程中最棘手的一环。当我们把规范转化为Elixir 代码时，模型就像是找到了捷径。它会觉得，在这个拥有原生进程监控的优秀运行时里，有这么多现成的原语可以用。这种做法很聪明，通过选择与领域自然映射的技术栈，让规范变得更容易实现。这里完全没有人类参与。所以我自己会不会写 Elixir 并不重要，这不会影响我们选择最合适的工具。
（关于建立信任）大家对于这种低成本分发软件和创意的方式感到非常兴奋，它把我们的生产力提高了五倍。这证明了一种持久的模式，即把人类从流程中解放出来，并找到信任输出的方法。我们在规范中分享的视频，就是我们希望 AI Agent 在创建合并请求时附带的那种视频。这是建立信任的关键。我不想看你在编辑器里操作的全程录屏。我只希望你用你的方式向我证明，代码是高质量的、可以合并的，并把整个过程压缩成我一眼就能看懂的信息。
15
在追求极致速度的小型模型与百万上下文推理模型间寻找平衡
既然代码是可丢弃的，你会一直使用高推理模型吗？你怎么看像5.3 Spark 这种追求速度的小型模型？目前模型在处理“从零到一”的创意转化和复杂重构方面还存在哪些局限性？
Ryan Lopopolo:Spark 和那些具备超高推理能力的模型完全不同，它是一个追求极致速度的小型模型。我还没完全想好怎么用它，我曾试着用它处理一些本该由高推理模型完成的任务，结果它在写出第一行代码之前就耗尽了上下文额度。对于 Spark，我觉得它非常适合快速构建原型、探索创意或者更新文档。它在接收反馈并将其转化为代码检查规则方面表现卓越。
（关于局限性）目前的模型还没法直接根据一个全新的创意，一次性生成一个完整的原型。这是我目前投入精力最多的地方，即如何将一个全新产品的设计图转化成可运行的产品。此外，那些极其复杂的架构重构依然最耗费精力。在这些任务中，我需要频繁介入。但我预计这些很快都会改善，永远不要对赌模型输。唯一的挑战在于如何将我脑海中的想法转化为模型可理解的上下文，尤其是在处理那些从零开始的空白项目时。
16
Frontier 企业平台与AGI
OpenAI 前不久发布的 Frontier 平台是单一产品还是产品系列？它的受众是谁？此外，你们提到的内部数据 AI Agent 如何解决“收入定义”这种在大型企业中常见的语义歧义？
Ryan Lopopolo:Frontier 是我们致力于推动各种规模企业实现 AI 转型的核心平台。我们的目标是让企业能够轻松地在办公环境中部署高度可观察、安全受控且身份明确的 AI Agent。我们希望它能与公司原生的身份访问管理（IAM）体系无缝衔接，接入现有的安全工具。AI Agent SDK 是其核心组件，旨在为开发者提供一套默认可用的 Harness。
（关于受众与数据）这个仪表板是为 IT 部门、合规团队、安全团队准备的，它是隐藏在前端体验之下的巨大冰山。我们发布了一个内部数据 AI Agent，它利用了 Frontier 的技术，让数据本体能够被 AI Agent 理解。公司里可能只有五个数据科学家能定义这种“黄金标准”。要真正理解业务是如何运营的，AI Agent 必须搞清楚收入的定义、客户细分以及产品线的构成。这不仅是编程能力，更是构建 Harness 的关键。
在你们的代码库里甚至有`core_beliefs.md` 这样的文件。你们是如何将愿景、甚至是 Slack 里的迷因（Meme）文化同步给 Agent 的？对于 OpenAI 提到的 AGI 五阶段，我们讨论的这些系统是否已经达到了等级 4 或 5？在 Harness 工程与原生模型训练之间，你们如何平衡？
Ryan Lopopolo:`core_beliefs.md` 记录了团队成员、产品目标、试点客户等核心信息，甚至包括未来 12 个月的愿景。这些背景信息决定了我们构建软件的方式，所以也必须将其同步给 AI Agent。我们甚至训练了 AI Agent 如何生成那种深度迷因。5.4 模型在理解迷因方面表现极其出色。
（关于 AGI 与训练）我的团队正在飞速推进。我希望 ChatGPT 也能学习我们的迷因文化、产品细节和工作流程。这涉及到一种根本性的张力：是应该在 Harness 上投入更多，还是在训练中让模型原生具备这些能力。我认为我们的成功在于让模型获得了更好的品味。这在强化学习中就相当于同策略Harness。如果我们能以原生于代码的方式构建这些护栏，它就能与模型进化完美契合，且不产生任何摩擦。
