本集简介
双语字幕
仅展示文本字幕，不包含中文音频；想边听边看，请使用 Bayt 播客 App。
我认为在使用Codex和Harness构建AI产品方面，确实有一个值得探索的有趣领域。
I do think that there is an interesting space to explore here with Codex, the Harness as part of building AI products.
对吧？
Right?
目前在让模型擅长编程方面，有着巨大的推动力。
There's a ton of momentum around getting the models to be good at coding.
我们看到，随着每个增量模型的发布，任务复杂性都有了显著提升；如果你能弄清楚如何将你想要构建的产品或试图解决的用户旅程转化为代码，那么使用Codex Harness来帮你解决这个问题就非常自然了。
We've seen big leaps in, like, the task complexity with each incremental model release where if you can figure out how to collapse a product that you're trying to build, a user journey that you're trying to solve into code, it's pretty natural to use the Codex Harness to solve that problem for you.
它已经完成了所有布线工作，你只需通过提示词与模型沟通，让它自行运行。
It's done all the wiring and lets you just communicate in prompts to let the model cook.
你需要退一步思考。
You have to step back.
对吧？
Right?
你需要以系统思维来看待问题，不断追问：代理在哪些地方犯了错误？
Like, you need to take a systems thinking mindset to things and constantly be asking, where is the agent making mistakes?
我把时间花在了哪里？
Where am I spending my time?
我如何才能避免在未来再花这些时间？
How can I not spend that time going forward?
然后建立对我所实施的自动化的信心，这样我
And then build confidence in the automation that I'm putting in place so I
就解决了SDLC的这一部分。
have solved this part of the SDLC.
好的。
Alright.
我们现在与来自OpenAI的瑞安·洛波波洛在演播室里。
We're in the studio with Ryan Lopopolo from OpenAI.
欢迎。
Welcome.
嗨。
Hi.
感谢你来到旧金山，也感谢你抽出时间与我们交流。
Thanks for visiting San Francisco, and thanks for spending some time with us.
是的。
Yeah.
谢谢。
Thank you.
我非常兴奋能来到这里。
I'm super excited to be here.
你写了一篇关于线束工程的爆款文章。
You wrote a blockbuster article on a harness engineering.
这很可能会成为这一新兴领域的奠基之作。
It's probably going to be the defining piece of this emerging discipline.
谢谢。
Thank you.
能感觉到我们定义了这场讨论，这真的很有趣
It is it's been fun to feel like we've defined the discourse
在某种意义上。
in some sense.
让我们稍微 contextualize 一下你做的第一个播客。
Let's contextualize a little bit this first podcast you've ever done.
是的。
Yes.
谢谢你和我们共度这段时间。
And thank you for spending it with us.
这背后是怎么回事？
What is where is this coming from?
你属于哪个团队？
What team are you in?
诸如此类的事情。
All that jazz.
当然。
Sure.
当然。
Sure.
我负责前沿产品探索和新产品开发，专注于OpenAI前沿领域，这是我们为企业安全、大规模部署智能体并实现良好治理的企业平台。
I work on frontier product exploration, new product development in the space of OpenAI Frontier, which is our enterprise platform for deploying agents safely at scale with good governance in any business.
我和我的团队的任务是找到新颖的方式，将我们的模型封装成产品，作为解决方案销售给企业。
And the role of me and my team has been to figure out novel ways to deploy our models into package and products that we can sell as solutions to enterprises.
你有相关背景。
And you have a background.
我就顺便提一下。
I'll just squeeze it in there.
Snowflake、Brex、Stripe、Citadel。
Snowflake, Brex, Stripe, Citadel.
是的。
Yes.
对。
Yes.
所以这与客户的整个生命周期有关。
So then the link kind of customer entire life.
是的。
Yes.
你想要的那种确切的客户
The exact kind of customer that you want to
所以我要说，我其实没料到你的背景是这样的。
So I'll say I was actually I didn't expect the background.
当我看你推特的时候，看到的完全是与此相反的内容。
When I look at your Twitter, I'm seeing the opposite of stuff like this.
所以你的思维模式是那种全速推进AI编码，关于随意折腾，比如在你的Waymo车上把笔记本电脑扣上。
So you've got the mindset of, like, full send AI coding, stuff about slop, like, buckling in your laptop on your Waymos.
是的。
Yes.
然后我看了你的个人资料。
And then I look at your profile.
我觉得，你在另一个方面也是对的。
I'm like, oh, you're just, like, you're correct in the other end too.
所以是完美的结合。
So perfect mix.
完美的结合。
Perfect mix.
当一个AI极致主义者还挺有趣的。
I it's quite fun to be AI maximalist.
如果你要践行这种人设，OpenAI 就是做这件事的地方。
If you're gonna live that persona, OpenAI is the place to do it.
而且这很
And it's
我说的就是代币。
token is what I say.
是的。
Yeah.
这确实很有帮助，因为我们内部没有任何使用限制，我可以直接去
Certainly helps that we have no rate limits internally, and I can go,
就像你说的，全力推进这件事。
like you said, full send at this thing.
是的。
Yeah.
对。
Yeah.
所以OpenAI前沿团队以及你们在OpenAI前沿内部的特别小组
So the OpenAI Frontier and your special team within OpenAI Frontier
我们被赋予了一些自由发挥的空间，这真的非常令人兴奋。
We had been given some space to cook, which has been super, super exciting.
这就是为什么我一开始设定了一个相当激进的限制：自己不写任何代码。
And this is why I started with kind of a out there constraint to not write any of the code myself.
我当时在想，如果我们试图打造能够部署到企业终端的智能体，它们应该
I was figuring if we're trying to make agents that can be deployed into end enterprises, they should
能够完成所有
be able to do all
我所做的事情。
the things that I do.
在与这些编码模型和编码框架合作了六个月、七个月甚至八个月后，我确实觉得模型和框架的能力已经足够强大，足以在能力和任务执行上与我相当。
And having worked with these coding models, these coding harnesses over six, seven, eight months, I do feel like the models are there enough, the harnesses are there enough, where they're isomorphic to me in capability and the ability to do the job.
因此，从‘我不能写代码’这个约束出发，意味着我完成工作的唯一方式就是让智能体来替我完成。
So starting with this constraint of I can't write the code meant that the only way I could do my job was to get the agent to do my job.
在那之前，让我稍微补充一点背景信息。
And like a just a bit of background before that.
这基本上就是那篇文章。
This is basically the article.
你们所做的，是在五个月内开发了一个内部工具，没有写一行代码，而整个代码库总共有上百万行代码。
So what you guys did is five months of working on an internal tool, zero lines of code, over a my a million lines of code in the total code base.
你们说这比你们自己动手做快了10倍。
You say it was Senex more like, it was 10x faster than you would have if you had done it by end.
是的
Yeah.
这就是我们当时的心态。
That was the mindset going into this.
对吧？
Right?
对。
Right.
没错。
That's right.
我们最初使用的是Codex CLI的早期版本和Codex Mini模型，显然它的能力远不如今天的模型，但这也构成了一个非常好的约束条件。
Started with some of the very first versions of Codex CLI with the Codex Mini model, which was obviously much less capable than the ones we have today, which was also a very good constraint.
对吧？
Right?
让模型为你构建一个产品功能，而它却无法把各个部分拼凑起来，这种感觉非常直观，这也定义了我们当时的一种心态：每当模型无法完成时，你总是打开任务，双击进去，拆解成更小的模块，然后再重新组合成更大的目标。
It's quite a visceral feeling to ask the model to build you a product feature and it just not being able to assemble the pieces together, which kind of defined one of the mindsets we had for going into this, which is whenever the model just cannot, you always pop open the task, double click into it, and build smaller building blocks that then you can reassemble into the broader objective.
老实说，这样做非常痛苦。
And it was quite painful to do this, honestly.
头一个半月，我的效率比我平时慢了十倍。
The first month and a half was 10 times slower than I would be.
但因为我们付出了这个代价，最终我们得到了比任何单个工程师都更高效的结果，因为我们构建了工具，搭建了让智能体完成整个任务的装配站。
But because we paid that cost, we ended up getting to something much more productive than any one engineer could be because we built the tools, the assembly station for the agent to do the whole thing.
但确实如此。
But yeah.
接下来，我们经历了GPT-5.1、5.2、5.3、5.4这些模型版本，观察它们各自的特性与不同的工作风格，这也意味着我们必须随着模型的升级不断调整代码库。
So onward to g p d five, five one, five two, five three, five four to go through all these model generations and see their kind of quirks and different working styles also meant we had to adapt the code base to change things up when the model was revved.
这里有一个有趣的地方：当时的Codex Harness并没有后台Shell，这意味着我们可以依赖阻塞式脚本来完成长期任务。
One interesting thing here is five two, the Codex Harness at the time, did not have background shells in it, which means we were able to rely on blocking scripts to perform long horizon work.
但到了5.3版本并引入后台Shell后，模型变得不那么有耐心，也不太愿意阻塞了。
But with five three and background shells, it became less patient, less willing to block.
因此，我们必须重新设计整个构建系统，确保它能在一分钟内完成。
So we had to retool the entire build system to complete in under a minute.
这可不是我预期能在有不同意见的代码库中能实现的事情。
And this is not a thing I would expect to be able to do in a code base where people have opinions.
但因为我们唯一的目标是让代理高效运行，所以在一周内，我们从自定义的 makefile 构建系统，先后切换到了 Bazel、Turbo，最后定在 NX，并且就停在那里，因为那时构建速度已经很快了。
But because the only goal was to make the agent productive, over the course of a week, we went from a bespoke make file build to Bazel to Turbo to NX and just left it there because builds were fast at that
点。
point.
有意思。
Interesting.
再多讲讲从 Turbo 到 NX 的转变吧。
Talk more about Turbo to NX.
这很有趣。
That's interesting.
因为这恰恰是其他人走的另一个方向。
Because that's the other direction that other people have been doing.
说到底，我对实际的前端仓库架构并没有太多经验。
Ultimately, I have not a lot of experience with actual front end repo architecture.
你是在说杰西卡给我们搞了这个东西？
You're telling me that Jessica built us this guy.
所以我想，我认识NXT团队。
So I'm like, I know the NXT team.
我了解Jared Palmer的Turbo，我觉得这确实是个有趣的竞品对比。
Know Turbo from Jared Palmer, I'm like, yeah, that's an interesting competitor comparison.
我们当时要攻克的难题，就是让它变快。
The hill we were climbing, right, was make it fast.
有没有涉及微前端？
Is there a micro micro front ends involved?
就是说，复杂到什么程度？
It's like, how how complex?
React。
React.
基于Electron的单体应用。
Electron based single app sort of thing.
而且必须在一分钟以内。
And must be under a minute.
这是一个有趣的限制。
That's an interesting limitation.
我其实对后台货架这一块不太熟悉。
I'm actually not super familiar with the background shelf stuff.
可能在5.3版本中已经讨论过了。
Probably was talked about in the five three release.
这意味着Codex能够在后台启动命令，然后继续工作，同时等待它们完成。
It basically means that Codex is able to spawn commands in the background and then go continue to work while it waits for them to finish.
因此，它可以启动一个耗时的构建任务，然后继续审查代码，例如。
So it can spawn an expensive build and then continue reviewing the code, for example.
是的。
Yeah.
这有助于提高用户使用该工具时的时间效率。
And this helps it be more time efficient for the user invoking the harness.
我想再明确一下，这一分钟到底有什么意义？
And I guess and just to really nail this, like, what does one minute matter?
是一分钟还是五分钟？
Like, one or five?
好的。
Okay.
我们希望内部循环越快越好。
We want the inner loop to be as fast as possible.
明白了。
Okay.
一分钟只是一个方便的整数，而且我们能够做到。
One minute was just a nice round number and we were able to
刚好达到。
hit it.
如果没完成，就会终止它吗？
And if it doesn't complete, it kills it or some something?
不。
No.
我们只是将其视为一个信号，表明我们需要停止当前的操作，双击并分解构建图，以便将流程拉回正轨，让代理能够继续运行。
We just take that as a signal that we need to stop what we're doing, double click, decompose the build graph a bit to get us behind back under so that we can enable the agent to continue to operate.
这几乎就像一个棘轮。
It's almost like you're it's like a ratchet.
就像你在强制要求一样。
Like, it's like you're forcing Yeah.
建立构建时间的纪律，因为如果你不这样做，它就会不断增长。
Build time discipline because if you don't, it'll just grow and grow.
没错。
That's right.
你提到，你目前工作的软件构建时间是十二分钟。
And you mentioned that Like, current like, the software I work on currently is at twelve minutes.
这太糟糕了。
It sucks.
这是我过去在平台团队中的经验：你们会设定一个可接受的构建时间范围，任由它上升到突破界限，然后花两到三周时间把它拉回范围的下限并停下来。
This has been my experience with platform teams in the past where you have an envelope of acceptable build times and you let it go up to breach, and then you spend two, three weeks to bring it back down to the lower end of the envelope and stop.
但因为令牌成本如此低廉，而且模型可以高度并行，我们可以持续不断地维护这件事，确保这些不变量得以保持，这意味着代码和软件开发生命周期中的差异大大减少，从而让我们能够简化流程，并在编写软件时更多地依赖这些不变量。
But because tokens are so cheap Yeah.
而且由于令牌成本极低，且模型可以高度并行，我们可以持续不断地维护这一过程，确保维持这些不变量，这意味着代码和软件开发生命周期中的分散性大大降低，从而让我们能够以更简化的方式运作，并在编写软件时更依赖这些不变量。
And so insanely parallel with the model, we can just constantly be gardening this thing to make sure that we maintain these invariants, which means there's way less dispersion in the code and the SDLC, which means we can simplify in a way and rely on a lot more invariance as we write the software.
太棒了。
Lovely.
你在文章中提到，人类成了瓶颈。
You mentioned in your article, like humans became the bottleneck.
对吧？
Right?
你们最初是一个三人团队。
You kicked off as a team of three people.
你们却输出了百万行代码，达成了1500个拉取请求。
You're putting out a million line of code, like 1,500 PRs.
那么，这种心态到底是什么？
Basically, what's the mindset there?
尽管代码是可丢弃的，但你们还是做了大量的代码审查。
So as much as code is disposable, you're doing a lot of review.
文章中很多地方谈到，你们希望把一切重新表述为提示。
A lot of the article talks about how you wanna rephrase everything is prompting.
一切就是代理看不到的东西。
Everything is what the agent can't see.
这有点像垃圾，对吧？
It's kind of garbage, right?
你不应该把它留在那里。
You shouldn't have it in there.
那么，你们在构建这个系统时的大致思路是什么？之后又是如何解决‘人类只是做PR审查’这个问题的？
So what's like the high level of how you went about building it and then how you address, okay, humans are just PR review.
也就是说，人类在这个流程中是参与其中的吗？
Like, is human in the loop for this?
我们甚至已经超越了人类审查代码的阶段。
We've moved beyond even the humans reviewing the code as well.
目前大多数人工审查都是在合并之后进行，但
Most of the human review is post merge at this point, but
哇。
Wow.
合并之后。
Post merge.
合并。
Merge.
这根本算不上审查。
That's not even review.
这只不过是让我们自己读一读，图个心安罢了。
That's just let's just make ourselves happy by reading it.
从根本上说，这个模型很容易陷入瘫痪。
Fundamentally, the model is trivially paralyzable.
对吧？
Right?
只要我愿意投入足够的GPU和令牌，我就能拥有足够的算力来处理我的HUD基础工作。
As many GPUs and tokens as I am willing to spend, I can have capacity to work on my HUD base.
唯一真正稀缺的是我团队成员的同步人类注意力。
The only fundamentally scarce thing is the synchronous human attention of my team.
一天只有这么多小时。
There's only so many hours in the day.
我们得吃午饭。
We have to eat lunch.
我想睡觉，但很难停下来去打扰这台机器，因为它让我忍不住想继续喂它。
I would like to sleep, although it's quite difficult to stop poking the machine because it makes me want to feed it.
你得退一步。
You have to step back.
对吧？
Right?
你需要以系统思维的角度来看待问题，不断追问：代理在哪些地方犯了错误？
Like, you need to take a systems thinking mindset to things and constantly be asking, where is the agent making mistakes?
我花时间的地方在哪里？
Where am I spending my time?
我如何才能避免在未来再花这些时间？
How can I not spend that time going forward?
然后建立对所部署自动化系统的信心，所以
And then build confidence in the automation that I'm putting in place, so
我已经解决了这一部分的
I have solved this part of
软件开发生命周期。
the SDLC.
通常这种情况是，我们一开始必须非常关注代码，因为代理缺乏正确的构建模块，无法生成模块化、合理分解、可靠且可观察的软件，也无法真正构建出可用的前端功能。
And usually what that has looked like is like, we started needing to pay very close attention to the code because the agent did not have the right building blocks to produce modular software that decomposed appropriately, that was reliable and observable and actually accrued a working front end in these things.
对吧？
Right?
因此，为了不把所有时间都花在终端前，一次只做一两件事，我们投入了为模型提供可观测性，也就是这里帖子中展示的那张图。
So in order to not spend all of our time sitting in front of a terminal at most doing one or two things at a time, invested in giving the model that observability, which is that that graph that's in the post here.
是的。
Yeah.
我们来一步步分析一下。
Let's walk through this.
追踪是从哪里开始的？哪个先出现？
Traces Which and existed first?
我们最初只用了应用程序，从 Vector 到所有这些登录指标 API，加起来大概只花了我半个下午的时间。
We started with just the app and the whole rest of it from vector through to all these login metrics APIs was, I don't know, half an afternoon of my time.
我们有意选择了高级别、开发效率高的工具。
We have intentionally chosen very high level, fast developer tools.
现在市面上有很多很棒的工具。
There's a ton of great stuff out there now.
我们大量使用 Mies，它让我们能轻松地在本地开发环境中下载所有用 Go 编写的 Victoria 堆栈二进制文件。
We use Mies a bunch, which makes it trivial to pull down all these Go written Victoria stack binaries in our local development.
用一点点 Python 脚本把所有这些组件启动起来，然后就可以开始了。
Tiny little bit of Python glue to spin all these up, and off you go.
这里有一件很巧妙的事，我们尽可能地颠倒了传统流程：不是先搭建环境再让编码代理进入，而是直接以编码代理为入口点，也就是 Codex。
One neat thing here is we have tried to invert things as much as possible, which is instead of setting up an environment to spawn the coding agent into, instead we spawn the coding agent, like that's the entry point, just Codex.
然后我们通过技能和脚本赋予 Codex 能力，让它可以根据需要自行启动整个系统，并告诉它如何设置一些环境变量，使本地开发的应用指向它自己启动的系统。
And then we give Codex via skills and scripts the ability to boot the stack if it chooses to, and then tell it how to set some end variables so the app in local dev points at this stack that it has chosen to spin up.
我认为，这正是推理模型与过去那些四零和四O模型的根本区别：过去的模型无法思考，你必须把它们放进一个预设好状态转换的盒子中。
And this, I think, is like the fundamental difference between reasoning models and the four ones and four o's of the past, where these models could not think, so you had to put them in boxes with a predefined set of state transitions.
而在这里，我们让模型和运行框架本身成为整个盒子，并给予它多种可选路径，同时提供足够的上下文，让它能做出明智的决策。
Whereas here, we have the model, the harness be the whole box, and give it a bunch of options for how to proceed with enough context for it to make intelligent choices.
所以，很多工作其实都围绕着脚手架展开。
So sales So like a lot of that is around scaffolding.
对吧？
Right?
是的。
Yes.
以前的代理，你会定义一个框架。
Previous agents, you would define a scaffold.
它会在那个循环中运行，然后重试。
It would operate in that loop, try again.
当我们使用推理模型时，发现如果没有框架，它们的表现似乎更好。
That's pivoted off from when we've had reasoning models, they're seeming to perform better when you don't have a scaffold.
对吧？
Right?
让它们也进入一些特定领域，比如你的 spec.md，以及非常短的 agent.mg 或 agentmd？
Let them and you go into like niches here too, like your spec.md and like having a very short agent.mg agentmd?
是的。
Yes.
对。
Yes.
好的。
Yeah.
所以你在这里甚至明确了它是什么，但我喜欢这个目录。
So you even lay out what it is here, but I like the table of contents.
我认为像这样的东西真的能帮助人们，因为每个人都在尝试做这件事。
I think stuff like this, it really helps guide people because everyone's trying to do this.
这种结构也让向仓库中添加新内容变得极其便宜，同时惠及人类和代理。
This structure also makes it super cheap to put new content into the repository to smear both the humans and the agents.
你重新发明了技能。
You you reinvented skills.
对吧？
Right?
一个大型代理，从第一性原理出发的技能。
One big agent and Skills from first principles.
哦，当我们刚开始做这件事时，还没有技能这个概念。
Oh, skills did not exist when we started doing this.
你有一个简短的一百行总目录，然后还有一些小技能。
You you have a short one one hundred line overall table of contents, and then you have little skills.
对吧？
Right?
核心信念、MD、技术追踪器。
Core beliefs, MD, tech tracker.
是的。
Yeah.
是的。
Yeah.
这个技能结束了。
The skill is over.
技术追踪器和质量评分非常有趣，因为这本质上是一个小小的框架，就像一个Markdown表格，作为Codex的入口，用来审查我们在应用中定义的所有业务逻辑，评估其与这些已记录的防护措施的匹配程度，并为其自身提出后续工作建议。
The the tech jet tracker and the quality score are pretty interesting because this is basically a tiny little scaffold, like a markdown table, which is a hook for Codex to review all the business logic that we have defined in the app, assess how it matches all these documented guardrails, and propose follow-up work for itself.
在使用Beads和所有这些工单系统之前，我们只是将后续工作作为笔记记录在Markdown文件中，然后可以安排一个代理在定时任务中自动处理这些任务。
Before beads and all these ticketing systems, we were just tracking follow-up work as notes in a markdown file, which we could spawn an agent on a cron to burn down.
有一件非常巧妙的事情，那就是模型从根本上渴望文本。
There's this really neat thing that, like, the models fundamentally crave text.
所以我们在这里做的很多工作，就是找到将文本注入系统的方法。
So a lot of what we have done here is figure out ways to inject text into the system.
对吧？
Right?
当我们因为超时缺失而收到页面通知时，比如，我可以在 Slack 上@Codex 并说：我会通过添加超时来解决这个问题。
When we get a page because we're missing a timeout, for example, I can just add Codex in Slack on that page and say, I'm gonna fix this by adding a timeout.
请更新我们的可靠性文档，要求所有网络调用都必须设置超时。
Please update our reliability documentation to require that all network calls have timeouts.
因此，我不仅做了一次性的修复，还持久地将关于‘什么是良好标准’的流程知识编码了下来。
So, I have not only made a point in time fix, but also like durably encoded this process knowledge around what good looks like.
是的。
Yeah.
我们在根编码代理执行任务时将这些内容提供给它，但你也可以用它来提炼测试用例，或用于代码审查代理，后者会指出相同的问题，从而缩小生成代码的可接受范围。
And we give that to the root coding agent as it goes and does the thing, but you can also use that to distill tests out of, or a code review agent, which is pointed out the same things to narrow the acceptable universe of the code that's produced.
我认为，对于这类做法，我担心的是：你可能以为自己做出了正确的决定，因为这些内容被永久地固化在所有地方了，是的。
I think one of the concerns I have with that kind of stuff is you think you're making the right call by making it's persisted for all time across everything Yes.
但你却没有考虑到需要做的例外情况。
But then you didn't think about the exceptions that you need to make.
对吧？
Right?
然后你就得回滚。
And then you have to roll it back.
其中一部分原因也是，有时候它确实能很好地遵循指令。
Part of it is also Sometimes it can follow instructions too.
这在某种程度上是一种技能。
It's somewhat a skill.
对吧？
Right?
所以它会决定何时使用工具。
So it determines when it uses the tools.
对吧？
Right?
就像，它不会在每次调用时都运行。
Like, it's not like it'll run at every call.
它会自行决定何时检查质量分数。
It'll determine when it wants to check quality score.
对吧？
Right?
是的。
Yeah.
而且我们在给这些代理的提示中，允许它们提出异议。
And we do, in the prompts we give these agents, allow them to push back.
当我们刚开始把代码审查代理添加到拉取请求时，Codex CLI 会在本地写入更改并推送一个拉取请求。
When we first started adding code review agents to the PR, it would be Codex CLI locally writes the change, pushes up a PR.
在这些拉取请求同步时，审查代理就会触发。
On those PR synchronizations, a review agent fires.
它会发布一条评论，我们要求 Codex 至少要确认并回应这些反馈。
It posts a comment, we instruct Codex that it has to at least acknowledge and respond to that feedback.
最初，驱动代码作者的Codex愿意被PR评审者压制，这可能导致情况无法达成一致。
And initially, the Codex driving the code author was willing to be bullied by the PR reviewer, which meant you could end up in a situation where things were not converging.
所以是的。
So Yeah.
我们不得不反复折腾。
Had to thrash.
我们必须在这两方面为提示词增加更多灵活性。
We had to add more optionality to the prompts on both of these things.
对吧？
Right?
评审代理被指示倾向于合并代码，不要提出优先级高于P2的问题。
The reviewer agents were instructed to bias toward merging the thing, to not surface anything greater than a p two in priority.
我们并没有明确定义P2，但我们给了它
We didn't really define p two, but we gave it
你们定义了P2吗？
You did define p two?
我们为它提供了一个用于评估其输出的框架。
We gave it a framework within which to score its output.
而比零级更严重的是更差的情况。
And then Greater than p zero is worse.
对吧？
Right?
是的。
Yes.
那个秘密的二级其实是还不错。
The secret p two is sort good.
零级意味着如果你合并这个，代码库就完蛋了。
P zero is you will code base if you merge this thing.
对吧？
Right?
但同时，在代码生成代理这一端，我们也赋予了它灵活选择：要么推迟，要么反驳评审反馈。
But also on the code authoring agent side, we also gave it the flexibility to either defer or push back against review feedback.
对吧？
Right?
这种情况经常发生。
It happens all the time.
对吧？
Right?
比如，我偶然注意到一个问题，就留下了一个代码评审意见，这可能会让工作量翻倍。
Like, I happen to notice something and leave a code review, which could blow up the scope by a factor of two.
我通常并不希望立即处理这个问题。
I usually don't mean for that to be addressed exactly in the moment.
这更多是作为一个提醒。
It's more of an FYI.
把它记到待办列表里，等到下一个修复周再处理之类的。
File it to the backlog, pick it up in the next fix it week sort of thing.
如果没有明确说明这是允许的，代码代理就会倾向于只执行它们一贯的做法——即严格遵循指令。
And without the context that this is permissible, the coding agents are gonna bias toward what they do, which is following instructions.
是的。
Yeah.
我想确认一下几件事。
I do wanted to check-in on a couple things.
对吧？
Right?
当然。
Like Sure.
所有的代码审查代理都可以自主合并。
All the coding review agent, it can merge autonomously.
我认为很多人都对这一点感到放心。
I think that's something that a lot of people are comfortable with.
你这里列出了代理们做了多少工作。
And you have a list here of how much agents do.
它们负责产品、代码和测试、CI配置和发布工具、内部开发工具、文档、评估框架、审查评论、管理代码库本身的脚本、生产仪表盘定义文件，等等一切。
They do products, code and tests, CI configuration and release tooling, internal dev tools, documentation, eval harness, review comments, scripts that manage the repository itself, production dashboard definition files, like everything.
是的。
Yes.
所以它们都在同时运行。
And so they're just all churning at the same time.
有没有记录显示，任何人类成员会
Is there, like, record that that any human on the
来暂停一切？
team pulls to stop everything?
因为我们在这里开发的是原生应用，而不是持续部署。
Because we are building a native application here, we're not doing continuous deploy.
所以发布分支的创建仍然需要人工介入。
So there is still a human in the loop for cutting the release branch.
我明白了。
I see.
在我们将应用推送到分发渠道之前，必须由经过授权的人类执行烟雾测试，诸如此类的流程。
We require a blessed human approved smoke test of the app before we promote it to distribution, these sorts of things.
所以你们是在开发应用，而不是在构建那种具有高可靠性（比如九个九）的基础设施，对吧？
So you're working on the app, you're not building, like, infrastructure where you have, like, nines of reliability, that kind of stuff?
没错。
That's correct.
没错。
That's correct.
好的。
Okay.
而且这里也要明确一点，所有这些工作都是在一个全新的代码库中进行的。
And also, like, full recognition here that all of this activity took in a completely greenfield repository.
不应该有任何疑问。
There's should be no Sure.
当然。
Sure.
这普遍适用于这种情况是
That this applies generally to This is
这是一个你要交付给客户的生产级产品。
a production thing you're gonna ship to customers.
当然。
Of course.
是的。
Yeah.
当然。
Of course.
所以这是真实的。
So this is real.
你提到过，你是从零开始创建这个仓库的，这是其中一件事。
And like one of the things there is you mentioned you started this as a repo from scratch.
头一个月的上手过程有点像倒着来。
The onboarding first month or so was pretty it was like working backwards.
对吧？
Right?
然后你必须与系统协作。
And then you have to work with the system.
而现在你已经到了那个阶段，你知道，你非常自主。
And now you're at that point where, you know, you're very autonomous.
我很好奇，那么，目前有多少人为干预呢？
I'm curious, like, okay, so what how human in the loop is it?
那么，你希望还能自动化哪些瓶颈？
So what are the bottlenecks that you wish you could still automate?
而其中一部分也在于，你认为模型的发展趋势会在哪些方面提升，从而减少人为干预？
And part of that is also like, where do you see the model trajectory improving and offloading more human in the loop?
我们刚发布了5.4版本。
We just got 5.4.
这真是一个
It's a really
很棒的绝佳模型，顺便说一下。
good Fantastic model, by the way.
是的
Yeah.
对
Yeah.
这是第一个融合了顶级编码能力的模型。
It's the first one that's merged top tier coding.
所以它具备了Codex级别的编码和推理能力。
So it's Codex level coding and reasoning.
所以将通用推理能力整合到了同一个模型中。
So general reasoning both in one model.
所以，计算机，现在
So And computer And now
我们现在用的是5.4版本。
we're Now we're the five four.
我现在可以直接让Codex写博客文章，而对这个版本，我不得不在聊天和
I can just have Codex write the blog post, whereas for this one, I had to balance between chat and
哦，我可能要失业了。
Oh, I need to I I might be out of a job.
天哪。
Oh my god.
哦。
Oh.
我
I
知道。
know.
你刚给了我一个点子，可以做一个完全由AI驱动的通讯，Five Four 可以做这个。
You just gave me an idea for a completely AI newsletter that five four could do.
是的。
Yeah.
我现在明白了。
I get it now.
这类事情只是闭环的一个例子。
This sort of thing is just one example of closing the loop.
对吧？
Right?
就像这样。
Like Yeah.
你提到的仪表盘，我们让Codex编写Grafana仪表盘的JSON并发布它们，同时还能响应告警，这意味着当它收到告警时，能准确知道哪些仪表盘被定义了，以及有哪些告警。
The dashboard thing you mentioned, we have Codex authoring the JSON for the Grafana dashboards and publishing them, and also responding to the pages, which means when it gets the page, it knows exactly which dashboards are defined and what alerts.
哪个告警是由代码库中的哪条确切日志触发的，因为所有这些信息都被整合在一起了。
What alert was triggered by which exact log in the code base because all of this stuff is collated together.
它必须掌控一切。
It has to own everything.
是的。
Yes.
对。
Yeah.
展开剩余字幕（还有 480 条）
是的。
Yeah.
这意味着，如果我们遇到一次没有触发告警的故障，它仍然可以访问现有的仪表盘集合、指标和日志，并能找出仪表盘或底层指标中的缺失部分，一次性加以修复。
And it means that if we have an outage that did not result in a page, it has the existing set of dashboards available to it, it has the existing set of metrics and logs, and can figure out where the gaps in the dashboard are, or in the underlying metrics, and fix them in one go.
同样地，就像全栈工程师能够从后端一直推动功能到前端一样。
In the same way, you would have a full stack engineer be able to drive a feature from the back end all the way to the front end.
所以，你们团队所做的大量工作，似乎是你们作为一个小团队，完全按照模型希望软件被编写的方式来工作。
So it it seems like a lot of the work you guys had to do was you as a small team are fully working for a way that the model wants the software to be written.
这更像是为了提升代码对代理的可读性，而非为了人类的可读性。
It's like less human legible for better code legibility, agent legibility.
你认为这对更广泛的团队会产生什么影响？
How do you think that affects broader teams?
所以在OpenAI，你们会像这样传达：软件就该这样写吗？
So one at OpenAI, do you liaison like this is how software should be written?
比如，你可以想象，当你加入一个新团队，带着这种 methodology 和这种思维模式。
Like, can imagine, say you join a new team with this methodology, this mindset.
团队进行代码审查、编写代码以及团队结构的方式，很多都是为了便于人类理解。
There's ways that teams do code review, teams write code, like teams are structured, and a lot of it is for human legibility.
我们应该全部互换吗？
Should we all swap?
这种做法如何在OpenAI内部乃至整个软件工程领域产生更广泛的影响？
Like, how does this play back one broader into OpenAI and then like broader into the software engineering?
那些采纳这种做法的团队，变化会相当剧烈。
Is it like teams that pick this up will have it's pretty drastic.
对吧？
Right?
你必须做出一个相当大的转变。
You have to make a pretty big switch.
他们应该直接全面推行吗？
Should they just full send?
是的。
Yeah.
这种心态就是我觉得自己与这个过程脱节了。
The mindset is very much that I'm removed from the process.
对吧？
Right?
我其实很难对代码层面的事情提出深入的意见。
I can't really have deep code level opinions about things.
这就像是在领导一个500人的技术团队。
It's as if I'm group tech leading a 500 person organization.
是的。
Yeah.
我不应该对每一个代码审查都深入到细节里。
Like, it's not appropriate for me to be in the weeds on every PR.
这就是为什么合并后的代码审查在这里是个很好的类比。
This is why that post merge code review thing is like a good analog here.
对吧？
Right?
比如，我会对当前编写的代码有一个代表性样本。
Like, I have some representative sample of the code as it is written.
我必须利用这些样本来推断团队正在面临的困难、他们需要哪些帮助、哪些地方进展顺利，然后我就可以把注意力转向其他地方。
I have to use that to infer what the teams are struggling with, where they could use help, where they're already moving quickly, and I can pivot my focus elsewhere.
是的。
Yeah.
因此，我对代码的具体写法其实并没有太多意见。
So I don't really have too many opinions around the code as it is written.
不过，我确实有一个命令基类，用于提供可重复的业务逻辑块，并且自带追踪、指标和可观测性。
I do, however, have a command base class, which is used to have repeatable chunks of business logic that comes with tracing and metrics and observability for free.
需要关注的不是这些业务逻辑的结构，而是它们是否使用了这个基础组件，因为我知道这默认就能带来杠杆效应。
And the thing to focus on is not how that business logic is structured, but that it uses this primitive because I know that's gonna give leverage by default.
对。
Yeah.
对。
Yeah.
回到
Back to
这种系统思维。
that sort of systems thinking.
你的博客文章中有一部分谈到了架构和品味的强制执行，以及你如何设定使用范围的边界。
And you have part of that in your blog post, enforcing architecture and taste, how you set boundaries for what's used.
还有一个部分是关于重新定义工程工作等内容。
There's also a section on redefining engineering and stuff.
但，是的，听到这些真的很有趣。
But, yeah, it's just it's interesting to hear.
随着模型变得越来越好，它们也越来越擅长提出这些抽象方案来解除自身的障碍，这又让我能够更高地站在技术栈上，更深入地洞察最终阻碍团队交付的根本问题。
And as the models have gotten better, they have gotten better at proposing these abstractions to unblock themselves, which again lets me move higher and higher up the stack to look deeper into the future on what ultimately block the team from shipping.
是的。
Yeah.
你提到，这主要是一个拥有百万行代码的 Electron 应用，但它也自行管理着自己的服务。
You mentioned so you this is primarily a it's like a 1,000,000 line of code based electron app, but it manages its own services as well.
所以这就像一种前端的后端类型的东西。
So it's like a back end for front end type thing.
我们确实有一个后端，但它托管在云端。
We do have a back end in there, but that's hosted in the cloud.
这种结构实际上存在于 Electron 的独立主进程和渲染进程内部。
This sort of structure is actually within the separate main and renderer processes within the Electron.
这正是 Electron 的工作方式。
That's just how Electron works.
是的。
Yeah.
当然。
Of course.
因此，我们也以同样的严谨性采用了 MVC 风格的分解，这非常有趣。
So Have also treated like MVC style decomposition with the same level of rigor, which has been very fun.
我有个有趣的双关语。
I have a fun pun.
这有点跑题了。
This is like a tangent.
MVC是模型-视图-控制器，任何全栈web开发者都知道这个。
MVC is model view controller, any sort of full stack web dev knows that.
但我这个AI原生版本叫模型-视图-爪子。
But my up AI native version of this is model view claw.
爪子， Harness。
Claws, harness.
没错。
That's right.
没错。
That's right.
我认为在Codex中，将Harness作为构建AI产品的一部分，这里确实有值得探索的空间。
I do think that there is an interesting space to explore here with Codex, the harness as part of building AI products.
对吧？
Right?
现在围绕让模型擅长编程的势头非常强劲。
There's a ton of momentum around getting the models to be good at coding.
我们看到，随着每个新模型的发布，任务复杂性都有了显著提升；如果你能弄清楚如何将你想要构建的产品或用户旅程转化为代码，那么使用Codex Harness来解决这个问题就非常自然。
We've seen big leaps in, like, the task complexity with each incremental model release where if you can figure out how to collapse a product that you're trying to build, a user journey that you're trying to solve into code, it's pretty natural to use the Codex Harness to solve that problem for you.
它已经完成了所有连接工作，你只需通过提示词与模型沟通，让它自行运行。
It's done all the wiring and lets you just communicate in prompts to let the model cook.
是的。
Yeah.
这真的非常有趣。
It's been very fun.
而且这也是以一种非常易于工程师理解的方式提升效率，简直太棒了。
And it's also a very engineering legible way of increasing It's fantastic.
对吧？
Right?
直接给模型脚本就行了。
Just give just give the model scripts.
你本来就会为自己写的那些脚本。
The same scripts you would already build for yourself.
是的。
Yeah.
对。
Yeah.
所以对听众来说，这是瑞安在说，软件工程或编码代理将吞噬知识工作，比如那些你通常认为需要单独构建代理的非编码部分。
So for listeners, this is Ryan saying that software engineering or coding agents will eat knowledge work, like the non coding parts that you would normally think, oh, you have to build a separate agent for it.
不用。
No.
从编码代理开始，然后向外扩展，OpenAI 就是这么做的。
Start with coding agent and go out from there, which OpenAI has.
对吧？
Right?
是的。
It's Yes.
底层是Pie。
Pie under the hood.
是的。
Yes.
基本上用代码定义你的任务。
Basically define your task in code.
一切都是编码代理。
Everything is a coding agent.
顺便说一下，既然我提到了，这可能是我们唯一提到的地方。
By the way, since I brought it up, it's probably the only place we bring it up.
你们有使用OpenAI吗？
Is there any OpenAI usage from you?
有任何吗？
Any
没有。
No.
没有。
No.
我没有多余的Mac mini在家里闲着。
Not for any I don't have any spare Mac minis rattling around my house.
你买得起。
You can afford it.
没有。
No.
我只是好奇OpenAI有没有因此发生什么变化，但可能还为时过早。
I just I'm curious if it's changed anything in OpenAI yet, but it's probably early days.
我想进一步探讨的是，你提到了工单系统和拉取请求，我想知道这两者是否都需要被淘汰或重新设计，以适应这种编程方式。
And then the the thing I wanna pull on here is, like, you mentioned ticketing systems and you mentioned PRs, and I'm wondering if both those things have to go away or be reinvented for this kind of coding.
Git本身对多代理协作非常不友好。
So the git itself and is, like, very hostile to multi agents.
是的。
Yeah.
我们大量使用工作树。
We make very heavy use of WorkTrees.
但即使如此，我昨天刚听了Cursor的一个播客，他们说正在放弃工作树，因为仍然存在太多合并冲突。
But, like, even then, like, I just did a dropped a podcast yesterday with Cursor saying then they said they're getting rid of work trees because it still has too many merge conflicts.
这太不直观了，不过你继续说。
It's too too unintuitive, but go ahead.
模型在解决合并冲突方面非常出色。
The models are really great at resolving merge conflicts.
是的。
Yeah.
要达到我不再需要在终端里同步参与的状态，我几乎不在乎是否存在合并冲突。
And to get to a state where I'm not synchronously in the loop in my terminal, I almost don't care that there are merge conflicts.
对。
Yeah.
可丢弃的。
Disposable.
是的。
Yeah.
我们调用一个美元土地技能，让Codex推送PR，等待人类和代理评审员，等待CI通过，如果有波动就修复，如果PR出现冲突就合并上游，等待所有检查通过，将其放入合并队列，持续处理波动直到代码进入主分支。
We invoke a dollar land skill and that coaches Codex to push the PR, wait for human and agent reviewers, wait for CI to be green, fix the flakes if there are any, merge upstream if the PR comes into conflict, wait for everything to pass, put it in the merge queue, deal with flakes until it's in main.
这就是完全委托的意义。
And this is what it means to delegate fully.
对吧？
Right?
在大型模型中，这很可能给人工带来相当大的负担，以完成PR的合并。
This is, in a very large model, probably a significant tax on humans to get PRs merged.
但代理完全有能力处理这些，而我几乎不需要操心，只需保持笔记本电脑开着即可。
But the agent is more than capable of doing this, and I really don't have to think about it other than keep my laptop open.
是的。
Yeah.
我以前是个控制狂，但现在我觉得，没错，你实际上能比我做得更好。
I used to be much more of a control freak, but now I'm like, yeah, actually, you could do a better job of this than me Yeah.
在有正确上下文的情况下。
With the right context.
是的。
Yes.
Harness引擎还有什么其他内容吗？
Anything else in Harness engine general?
就这一部分。
Just this piece.
我只是想确认一下，我觉得
I just wanna make sure we I think
有一件事，也许我在文章中没有说得特别清楚，但我从Twitter上听到有人觉得这很有趣，让他们感到困惑
one thing that I maybe didn't make super clear in the article that I heard on Twitter as an interesting That threw them
落在了他们身上。
onto them.
大家都在讨论什么？你的回应是什么？
What's the chatter and then what's your response?
最终，我们写在文档、测试和审查代理中的所有内容，都是为了将构建高规模、高质量、可靠软件所需的非功能性需求，融入到提示注入代理的机制中。
Ultimately, all the things that we have encoded in docs and tests and review agents and all these things are ways to put all the nonfunctional requirements of building high scale, high quality, reliable software into a space that prompt injects the agent.
我们要么将这些写成文档，要么在错误信息中添加链接，说明如何正确操作。
We either write it down as docs, we add links where the error message is told how to do the right thing.
所以，整个机制的核心就是从我团队所有工程师的头脑中提炼出：他们认为什么是好的、他们默认会怎么做，或者他们会如何指导新员工，以确保代码能够顺利合并。
So the whole meta of the thing is to basically tease out of the heads of all the engineers on my team what they think good looks like, what they would do by default, or what they would coach a new hire on the team to do to get things to merge.
因此，我们才会密切关注代理所犯的每一个错误。
And that's why we pay attention to all the mistakes mistakes that the agent makes.
对吧？
Right?
这段代码的编写与某些尚未被记录下来的非功能性需求产生了偏差。
This is code being written that is misaligned with some as yet not written down nonfunctional requirement.
抱歉。
Sorry.
网上的人误解了什么？
What did the online people misunderstand?
或者
Or
不。
No.
有人刚刚真的这么说。
What do you Somebody just literally said that.
就像是，哦，是的。
Was like, oh, yeah.
好的。
Okay.
这就是关键。
This is the thing.
这个
This
是
is what
我正在做。
I was doing.
你同意这一点。
You agree with it.
是的。
Yeah.
我明白了。
I see.
有意思。
Interesting.
还有另一件很有趣的事，我完全没想到的是，人们直接把文章链接发给Pi或Codex，说：把这个变成我的仓库。
One other neat thing, which I did totally did not expect is folks were just taking the link to the article and giving it to Pi or Codex and say, make my repo this.
你已经实现了所有递归。
You've achieved all recursions.
而且效果非常好。
And it was wildly effective.
真的吗？
Really?
它非常有效。
It was wildly effective.
我昨天其实试了五四。
Just actually is something I tried with five four yesterday.
我没太多时间。
I I didn't have that much time.
我当时在外面讲话。
I was like out speaking at something.
这是我的一个做法。
And this is one of my things.
我就想，好吧。
Was like, okay.
我有这篇文章。
I have this article.
我们能不能先搭建一下运行这个会是什么样子？
Can we just scaffold out what it would be like to run this?
我最初就是这么做的。
And I I did it first as that.
然后我想了想，好吧。
And then I was like, okay.
让我再开一个独立的代码库，试试看。
Let me take another little side repo and say, okay.
如果我要完全自动化这个流程，因为我还没写一行代码。
If I was to fully automate this like this, because I haven't written a line of code.
这就像一套完整的方案。
It's like a full set.
对吧？
Right?
我正在做的这个辅助事情。
The side thing I'm doing.
语音TTS。
Voice TTS.
我只是随便写写而已。
I'm just like slopping out whatever.
这根本不是生产环境的代码。
It's nothing production.
我在想，我要怎么才能做到这样呢？
I'm like, how would I make this like this?
这其实是个非常好的方法。
And it's actually, like, a really good way.
这是一种很好的方式，可以了解哪些地方可以改进，哪些地方可以调整，纯粹就是一种很好的分析过程。
It's, like, a good way to learn what could be changed, what could be like it's just a good analyzing.
对吧？
Right?
你把所有代码都给它。
You give it all the codes.
你给它所有上下文。
You give it all the context.
你给它这篇文章，它会很好地为你讲解。
You give it the article, and it walks you through it very well.
没错。
That's right.
没错。
That's right.
我想在我们转到Symphony之前，还有一件事我要讲一下布雷特·泰勒的回应。
I guess one more thing before we go to Symphony is I wanted to cover Brett Taylor's response.
我们请他上过节目。
We had him on the show.
他是你的董事长，这太不可思议了。
He is your chairman, which is wild.
是的。
Yeah.
他也在阅读你的文章，并且积极参与其中。
That he's reading your articles as well and, like, getting engaged in it.
他说软件依赖正在消失，基本上是这样。
He says software dependencies are going away, basically.
它们可以只是被打包进去，没错。
They can just be, like, vendored Yes.
回应。
Response.
完全同意。
A 100%.
完全同意。
100% agree.
你仍然使用 PromQL。
You still have PromQL.
你仍然要向 Datadog 付费。
You still pay Datadog.
你仍然需要为 Temporal 付费。
You still pay Temporal.
谢谢。
Thank you.
是的。
Yep.
我们现在能够内部化的依赖项复杂度，我觉得是低到中等水平。
The level of complexity of the dependencies that we can internalize is, I would say, low medium right now.
仅基于模型能力，什么是中等水平？
Just based on model capability What is the what is medium?
我觉得，几千行代码的依赖项，我们内部搞定完全没问题，上帝啊。
I would say like a a couple thousand line dependency is a thing that we could in house no problem God.
用一个下午的时间就能搞定。
In an afternoon of time.
其中一件很酷的事情是，这些代码中的大部分你可能根本不需要。
One neat thing about it is like probably most of that code you don't even need.
通过内部化和抽象，你可以剥离掉所有通用的部分，只专注于实现你所需的具体功能，是的。
Like, by in housing and abstraction, you can strip away all the generic parts of it and only focus on what you need to enable the specific thing Yes.
你正在构建的东西。
You're building.
我一直称这为垃圾插件的终结。
I've been calling this the end of bullshit plugins.
对。
Yeah.
因为当我发布一个开源项目时，我想接受所有东西。
Because it's so much when I publish an open source thing, I wanna accept everything.
要宽容，我想全部接纳。
Be liberal, I wanna accept.
这就是波斯特定律。
This is Postel's Law.
但这意味着有太多冗余和额外开销。
But that means there's so much bloat and so much overhead.
关于这一点，另一个不错的地方是，当我们在代码库中部署Codex安全功能时，它能够以比向上游推送补丁、等待发布、拉取更新并确保与我仓库中所有传递依赖兼容要低得多的摩擦成本，来深度审查和修改内部依赖。
One other neat thing about this too is when we deploy Codex security on the repo, it is able to deeply review and change the internalized dependencies in a much lower friction way than it would be to, like, push patches upstream, wait for them to be released, pull them down, make sure that's compatible with all the transitives I have in my repo and things like that.
因此，如果代码是免费的，且令牌成本低廉，那么将这些内容内部化也会容易得多。
So it's also much lower friction to internalize some of these things if code is free because the tokens are cheap sort of thing.
我认为，唯一反对这一点的理由基本上是规模测试，显然像Linux、MySQL这样的大型软件，甚至会调用数据日志和临时文件。
I think, like, the only argument I have against this is basically scale testing, which obviously the larger pieces of software like Linux, MySQL, he calls up even the data logs and temporals.
然后可能是安全测试，其中
And then maybe security testing where
是的。
Yes.
传统上，我认为是林纳斯·托瓦兹说过，开源安全是最好的消毒剂吗？
Classically, I think is it Linus Torvales who said the security open source is the best disinfectant?
许多是。
Many Is.
许多Is。
Many Iss.
如果你直接依赖这些依赖项并自己编写代码，你就得重新学习别人犯过的错误，是的。
And if in line your dependencies and code them up, you're gonna have to relearn mistakes from other people that Yep.
是的。
Yep.
而要将这些依赖项内部化，你就得从零开始，重新组装所有这些部分，是的。
And to internalize that dependency, you're back to zero, and you have to start reassembling all those bits and pieces to Yeah.
对当前编写的代码要有高度信心。
Have high confidence in the code as it is written.
是的。
Yeah.
甚至在这次介绍的开头部分，你就基本提到，所有内容都是由Codex编写的，包括内部工具。
Even part of the first intro of this, you basically mentioned, like, everything was written by Codex, including internal tooling.
对吧？
Right?
所以内部工具，比如当你在可视化正在发生的事情时，它会主动向我们输出内容。
So internal tooling, like, when you're visualizing what's going on, it's writing it forward to us.
是的。
Yeah.
我现在正在为AIE开发内部工具，我只是展示给他们看，他们就问：你花了多长时间？
I'm building internal tooling for AIE now, and, like, I just show them off and they're like, how long did you spend?
我确实花了时间。
And I that is spending time.
我只是给了它一个提示。
I just prompted it.
这里有个特别有趣的故事。
Very funny story here.
是的。
Yeah.
说吧。
Go
继续。
ahead.
我们已经将应用部署给了内部的前十几位用户。
We had deployed our app to the first dozen users internally.
我遇到了一些性能问题，所以我们请他们为我们导出一份追踪数据。
I had some performance issues, so we asked them to export a trace for us.
他们提供了一个tar包，交给了我们的值班工程师，他与Codex合作，出色地开发出了这个漂亮的本地开发工具Next。
Get a tarball, gave it to our on call engineer, and he did a fantastic job of working with Codex to build this beautiful local dev tool Next.
一个JS应用，你只需拖拽tar包进去，它就能可视化整个追踪数据。
Js app that you drag and drop the tarball in, and it visualizes the entire trace.
哦。
Oh.
太棒了。
It's fantastic.
只花了一个下午的时间。
Took an afternoon.
但其实这一切都不必要，因为你只需启动Codex，把tar包丢进去，问同样的问题，就能立即得到响应。
But none of this was necessary because you could just spin up Codex and give it the tarball and ask the same thing and get the response immediately.
所以某种程度上，为了让人更容易理解这个调试过程而进行优化是错误的。
So in a way, optimizing for human legibility of that debugging process was wrong.
这让他不必要的参与其中，而他本可以只是让Codex运行五分钟，就能得到同样的结果。
It kept him in the loop unnecessarily when instead he could have just let Codex cook for five minutes and gotten the same Yeah.
如果你的直觉是这样，这正是我们过去的做法，或者这是我过去会用的方式
You're if I your instincts here, this is how we used to do it or this is how I would have used
来解决它。
to solve it.
是的。
Yeah.
在这个本地可观测性栈中，当然，你可以部署Jaeger来可视化追踪数据，但我根本不会指望自己去查看这些追踪数据，因为我不会去写代码修复它们。
In this local observability stack, like, sure, you can deploy Jaeger to visualize the traces, but I wouldn't expect to be looking at the traces in the first place because I'm not gonna write the code to fix them.
对。
Yeah.
所以基本上，需要有这样的一个完整闭环体系，并由团队全面掌控。
So basically, there needs to be like this kind of house stack and owning the whole loop.
我认为这一点已经非常明确了，听起来你未来可能会更多地分享这方面的内容。
I think that is very well established and it sounds like you might be like sharing more about that in the future.
对吧？
Right?
是的。
Yeah.
我觉得我们很期待这么做，我们稍后会谈到Symphony，但关于我们以规范形式分发它的方式，我认为人们在Twitter上称之为幽灵库。
I I think we're excited to do we're gonna talk about Symphony in a little bit, but like the way we distribute it as a spec, which I think folks are calling ghost libraries on Twitter.
这真是个超棒的名字。
This is like a such a cool name.
这意味着与全世界分享软件的成本会大大降低。
It does mean it becomes much cheaper to share software with the world.
对吧？
Right?
你定义一个规范，说明如何构建你自己的版本，只需提供编码代理本地重新组装所需的最少信息。
You define a spec, how you could build your own, specifying as much as is required for a coding agent to reassemble it locally.
这里的流程非常棒。
The flow here is very cool.
我们把专有仓库中所有的脚手架都拿过来，新建了一个仓库，让Codex以我们的仓库为参考，编写规范。
Like, we have taken all the scaffolding that has existed in our proprietary repo, spun up a new one, ask Codex with our repo as a reference, write the spec.
我们让它启动一个TMux，启动一个独立的Codex来实现规范，等待完成，再启动另一个Codex和另一个TMux来审查规范或对比上游实现，并更新规范。
We tell it spin up a TMux, spawn a disconnected Codex to implement the spec, wait for it to be done, spawn another Codex and another TMux to review the speccom or review the implementation compared to upstream, and update the spec.
这样就能减少分歧。
So it diverges less.
然后你就像拉尔夫那样不断循环，直到得到一个能高保真复现系统现状的规范。
And then you just loop over and over Ralph style until you get a spec that is with high fidelity able to reproduce the system as it is.
这太棒了。
It's fantastic.
你基本上没有加入任何人类的偏见。
And you're basically you're not really adding any of your human bias in there.
对吧？
Right?
没错。
That's correct.
很多时候，人们写个规范，就觉得应该这么做，然后随便发挥一下，结果却不对。
A lot of times people write a spec and be like, okay, think it should be done this way and you'll riff on something and it's no.
他们本可以更妥善地处理这个问题。
They didn't could've just handled it.
换句话说，你其实还是在搭建脚手架。
Like, you're still scaffolding in a sense.
对吧？
Right?
我希望它这样完成。
I want it done this way.
它能更好地确定这个规范。
It can determine that spec better.
没错。
That's right.
没错。
That's right.
我最近一直在做评估相关的工作，有一部分我在想，一个智能体能否生成一个它自己无法解决的规范。
Part of me I'm I'm been working a lot on evals recently and part of me is wondering if an agent can produce a spec that it cannot solve.
它是否总是能实现它能想象到的事情，或者能想象出一些它根本无法做到的事情？
Is it always capable of things that it can imagine or can imagine things that it is impossible to do?
我认为在Symphony中，存在一个维度，区分了容易或困难、已建立或全新的任务。
I think with Symphony, we there's like this there's this axis where you have things that are easy or hard or established or new.
对吧？
Right?
我认为那些困难且全新的任务，仍然需要人类的参与。
And I think things that are hard and new is still something that the models need humans.
是的。
Yeah.
驱动。
Drive.
是的。
Yeah.
但我认为，只要提供合适的框架和推动代理完成任务的机制，其他那些象限的问题基本上已经解决了。
But I think those other quadrants are largely solved, given the right scaffold and the right thing that's gonna drive the agent to completion.
这居然被解决了，真是不可思议。
It's crazy that this solved.
这意味着，时间与注意力有限的人类可以专注于最困难的问题。
But it means that the humans, the ones with limited time and attention, get to work on the hardest stuff.
比如那些前方一片空白的纯粹未知问题，或者那些你根本不确定接口应如何设计的深度重构。
Like, the problems where it's pure white space out in front, or like the deepest refactorings where you don't know what the proper shape of the interfaces are.
而这正是我想投入时间的地方，因为它能为下一阶段的规模化奠定基础。
And this is where I wanna spend my time because it lets me set up for the next level of scale.
是的。
Yeah.
对。
Yeah.
太棒了。
Amazing.
让我们来介绍一下 Symphony。
Let's introduce Symphony.
我们之前时不时提到过它。
Think we've been mentioning it every now and then.
Elixir，一个有趣的选择。
Elixir, interesting option.
是的。
Yeah.
是的。
Yeah.
我再说一遍，这里的 Elixir 实现只是个衍生品。
I'm not Again, like, the Elixir manifestation here is just a derivative.
这是选择的模型吗？
Is it a model chosen?
是的。
Yeah.
是的。
Yeah.
是的。
Yeah.
它之所以选择这个，是因为过程监督和 gen servers 非常适合我们在这里进行的进程编排类型。
And it chose that because the process supervision and the gen servers are super amenable to the type of process orchestration that we're doing here.
你本质上是为每个正在执行的任务启动一个小守护进程，并推动其完成，这意味着通过使用 Elixir 和 Beam，模型可以免费获得大量功能。
You are essentially spinning up little daemons for every task that is in execution and driving it to completion, which means the model gets a ton of stuff for free by using Elixir and the Beam.
我不得不去快速学习一下 Beam 和 Elixir，我认为大多数人并不需要在那种并发规模下操作，但这是一个关于可恢复性等概念的好思维模型，而这些正是我在意的东西。
I had to go do a crash course in Beam and Elixir, and I think most people are not operating at that scale of concurrency where you need that, but it is a good mental model for resumability and all those things, and these are things I care about.
但给我讲讲 Symphony 的起源故事吧，你用它来做什么？
But tell me the story the origin story of Symphony, what do you use it for?
它是怎么形成的？
Is this how did it form?
有没有哪些你没有选择的废弃路径？
Maybe any abandoned paths that you didn't take?
在十二月，我们每位工程师每天大约有三到五个拉取请求。
At the December, we were at about three and a half PRs per engineer per day.
那是在5.2发布之前。
So it was before five two came out.
到了一月，大家都从假期回来。
In the January, everyone gets back from holiday.
有了5.2版本，而且仓库里没有其他工作，我们每位工程师每天的拉取请求数量上升到了五到十个。
With 5.2 and no other work on the repository, we were up in the five to 10 PRs per day per engineer.
我不知道你们怎么样，但这样频繁地切换真的非常耗费精力。
And I don't know about y'all, but, like, it's very taxing to constantly be switching like that.
每天结束的时候，我简直精疲力尽。
Like, I was pretty tapped out at the end of the day.
再说一遍，人类的时间到底花在了哪里？
Again, where are the humans spending their time?
他们把时间花在了在这些活跃的 TMUX 任务之间来回切换，以推动代理前进。
They're spending their time context switching between all these active TMUX pains to drive the agent forward.
是的。
Yeah.
不可能。
No way.
对。
Yeah.
所以，让我们再次构建一些东西，把自己从这个循环中移除。
So let's again build something to remove ourselves from the loop.
这就是我们在这里疯狂冲刺所寻找的方案：找到一种方法，让人不必再坐在终端前。
And this is what a frantic sprinted after here to find a way to remove the need for the human to sit in front of their terminal.
因此，我们对开发环境和自动启动代理进行了大量实验。
So a lot of experimentation with dev boxes and automatically spinning up agents.
这看起来像是一个完美的最终状态——我的生活就像在海滩上一样。
Like, it seems like a fantastic end state here where my life is beach.
我每天打开两次 Litter，对这些事情说 yes 或 no。
I open Litter twice a day and say yes, no to these things.
是的。
Yeah.
这再次为工作方式提供了一个非常有趣的视角，因为我对延迟的敏感度降低了。
And this is again a super, super interesting framing for how the work is done because I become more latency insensitive.
我对代码的现有写法不再那么执着。
I have way less attachment to the code as it is written.
我几乎完全没有投入在实际的创作过程中。
Like, I've had close to zero investment in the actual authorship experience.
所以如果代码很糟糕，我可以直接丢弃，不太在意。
So if it's garbage, I can just throw it away and not care too much about it.
在 Symphony 中，有一个重新修改的状态：当 PR 提交后，需要人类审查时，这个审查应该是低成本的。
In Symphony, there's this like rework state where once the PR is proposed and it's escalated to the human for review, it should be a cheap review.
它要么可以合并，要么不可以。
It is either mergeable or it is not.
如果不可合并，就将其移入返工状态，Elixir 服务会彻底删除整个工作树和拉取请求，然后从头开始重新生成。
And if it's not, you move it to rework, the Elixir service will completely trash the entire work tree and PR and start it again from scratch.
这又提供了一个机会来思考：为什么它是一团糟？
And this is that opportunity again to say, why was it trash?
对吧？
Right?
代理做了什么导致了这个问题。
What did the agent Yeah.
在将工单移回进行中之前，代理做了哪些修复。
Do that was fix Yeah.
所以人们再次将工单移入进行中状态。
That before moving the ticket to So people in progress again.
是的。
Yeah.
为什么这个功能不在 Codex 应用里？
Why is this not in the Codex app?
我想你们在Codex应用方面领先了。
I guess it's you guys are ahead of Codex app.
是的。
Yeah.
所以团队一直以来的工作方式就是尽可能地拥抱AI，走在前面。
So the way the team has been working is basically to be as AI pilled as possible and spread ahead.
我们所做的一些东西已经融入了我们众多的产品中。
And a lot of the things we have worked on have fallen out into a lot of the products that we have.
比如，我们曾与Codex团队深入合作，推动Codex应用的落地。
Like, we were in deep consultation with the Codex team to have the Codex app be a thing that exists.
对吧？
Right?
让技能成为Codex能够使用的功能。
To have skills be a thing that Codex is able to use.
所以我们不必自己开发来将自动化功能集成到产品中。
So we didn't have to roll our own to put automations into the product.
所以我们的所有自动重构代理都不必是这些手工编写的控制循环。
So all of our automatic refactoring agents didn't have to be these hand rolled control loops.
以一种不受Frontier和Codex产品开发束缚的方式，快速尝试找出有效的方法，这真的非常棒。
It has been really fantastic to be, in a way, unanchored to the product development of Frontier and Codex, and just very quickly try to figure out what works.
然后再找到可以广泛部署的可扩展方案。
And then later find the scalable thing that can be deployed widely.
这是一种非常有趣的运作方式。
It's been a very fun way to operate.
这当然很混乱。
It's certainly chaotic.
我经常搞不清楚代码的实际状态，因为我没有参与其中。
I have lost track very often of what the actual state of the code looks like because I'm not in the loop.
曾经有一段时间，我们直接将Playwright与Electron应用通过MCP连接起来。
There was one point where we had wired Playwright directly up to the Electron app with MCP.
我对MCP持相当悲观的态度，因为这个框架强制在上下文中注入所有这些令牌，而我对此没有发言权。
MCP is I'm pretty bearish on because the harness forcibly injects all those tokens in the context, and I don't really get a say over it.
它们干扰了自动压缩。
They mess with auto compaction.
代理可能会忘记如何使用工具。
The agent can forget how to use the tool.
在 Playwright 中，我真正想用的可能只有三个调用，但我却要为大量功能付出代价。
There's probably only, what, three calls in Playwright that I actually ever wanna use, so I pay the cost for a ton of things.
有人搞了一个本地守护进程，启动 Playwright 并提供一个极简的 Shim CLI 来控制它。
Somebody vibed a local daemon that boots playwright and exposes a tiny little shim CLI to drive it.
我完全不知道这件事已经发生了。
And I had zero idea that this had occurred.
因为对我来说，我运行 Codex，它就能做到，是的。
Because to me, I run Codex and it's able to Yeah.
驱动它，完全不知道这个东西的存在。
Drive Like no knowledge of this at all.
所以，是的。
So Uh-huh.
在人类协作中，我们不得不花大量时间进行同步的知识共享。
We have had, like in human space, to spend a lot of time doing synchronous knowledge sharing.
我们每天的站会长达四十五分钟，因为我们几乎必须广泛传达当前状态的理解。
We have a daily stand up that's forty five minutes long because we almost have to fan out the understanding of the current state.
是的。
Yeah.
我本来想说，这对单个人类配合多个智能体来说效果不错，但多个人类配合多个智能体就会引发一场爆炸式的复杂性。
Was gonna say, this is good for a single human multi agent, but multi human multi agent is a whole like poly explosion of stuff.
是的。
Yeah.
这正是为什么我们的应用程序必须采用如此僵化的、十万工程师级别的架构，因为我们必须找到方法来划分空间，避免人们互相干扰。
And that this is fundamentally why we have such a rigid, like, 10,000 engineer level architecture in the app because we have to find ways to carve up the space so people are not trampling on each other.
抱歉。
Sorry.
我不太明白你说的十万这个数字。
I don't get the 10,000 thing.
我漏掉了吗？
Did I miss that?
代码仓库的结构是500个MPM包。
The structure of the repository is like 500 MPM packages.
这相当于为一个七人团队设计的架构，但你可能觉得这很寻常。
It's like architecture to the access for what you would consider I think normal for a seven person team.
但如果每个人实际上负责10到50人，那么深入分解、分片以及清晰的接口边界就显得合理多了。
But if every person is actually like 10 to 50, then the, like, numbers on being super super deep into decomposition and sharding and, like, proper interface boundaries make a lot more sense.
是的。
Yeah.
这正是我提到微前端及其相关概念的原因。
To me, that's why I talked about micro front ends and I annexes from that world.
但很棒。
But cool.
这又回到了刚才的话题。
And it's just coming back to to to this.
我不确定你对如何协调这么多工作有什么其他想法。
I don't know if you have other thoughts on orchestrating so much work going going through this.
这够了吗？
Is this enough?
这有没有什么特别的时刻？
Is this, like, any moments?
看看情况会变得很有趣，比如在什么情况下。
It'll be interesting to see, like, where okay.
所以现在，你选择线性作为你的问题追踪工具。
So right now, you pick linear as your issue tracker.
对吧？
Right?
或者它真的是线性的吗？
Or it's like a is it actually linear?
这确实是线性的。
This is actually linear.
线性的？
Linear?
哦，这是线性的。
Oh, that's linear.
它是线性的。
It's linear.
哦，我知道我从来没看过
Oh, I know I never looked at
我不得不下载来看的演示视频。
The demo video I had to download to run.
所以
So
因为我是个Slack Maxie，但是的。
I because I'm a Slack Maxie, but yeah.
Linear线性也很棒。
Linear linear is also really good.
是的。
Yes.
我们确实很好地使用了Slack。
We do make a good use of Slack.
我们让Codex来处理所有这些低优先级的Slack小修小补，比如把知识同步到仓库里。
We we fire off Codex to do all these Like, we should low tier Slackity fix ups, the things that, like, sync that knowledge into the repository.
这非常便宜。
It's super cheap.
对。
Yeah.
直接用Codex做吧。
Just do it in Codex.
我最想推荐的是，OpenAI应该开发Slack。
My biggest plug is OpenAI needs to build Slack.
你们必须拥有Slack，自己打造一个，把这一切变成Slack。
You need to own Slack, build yours, to turn this into Slack.
我读过，但不太清楚
I did read don't know
你是怎么做的。
how to You did.
是的。
Yeah.
我会说，如果我们希望这些代理能够从事具有经济价值的工作，这正是我们的使命。
I would say that if we think that we want these agents to do economically valuable work, which is, like, this is the mission.
对吧？
Right?
我们希望人工智能被广泛部署，以完成具有经济价值的工作，那么我们就需要找到让它们与人类自然协作的方式，我认为，协作工具是一个值得探索的领域。
We want AI to be deployed widely to do economically valuable work, then we need to find ways for them to naturally collaborate with humans, which means collaboration tooling, I think, is an interesting space to explore.
是的。
Yeah.
完全正确。
Totally.
是的。
Yeah.
GitHub、Slack、Linear。
GitHub Slack, Linear.
是的。
Yeah.
那正是我的想法。
That was kinda my thing.
好的。
Okay.
我们现在看到的是，Codex 首先推出了 Codex 模型，然后是 CLI。
Where do we see right now, Codex has started Codex model, then CLI.
现在有了一个应用程序。
Now there's an app.
应用程序可以让我并行调用多个 Codex，但目前还没有针对 Codex 的优秀团队协作功能。
App can let me shoot off multiple Codexes in parallel, but there's no great team collaboration for Codex.
而且看起来你们团队对最终产出有一定发言权。
And it seems like your team had some say into what comes out.
对吧？
Right?
所以你们会和他们沟通。
So you talk to them.
Codex 就是这么来的。
Codex kind of was a thing from there.
如果你们处于前沿，那你们可能不会去关注的一些东西，你们希望别人去构建什么？
If you guys are on the bound, what stuff that, like, you might not focus on, but what do you expect other people to be building?
对吧？
Right?
所以那些效率高出五倍、五十倍的人，你们应该为自己的工作流程、团队构建非常垂直的工具吗？
So people that are, like, five x, 50 x ing, should you build stuff that's, like, very niche for your workflow, for your team?
应该更通用一些，以便其他人也能采用，还是更垂直一些？
Should it be more general so other people can adopt this or niche there?
因为部分原因在于，好吧，所有东西都只是内部工具吗？
Because because part of it is just, okay, is everything just internal tooling?
我们的一切都是自己搞的吗？
Do we have everything our own way?
比如，我们团队的运作方式有我们自己偏好的沟通方法，还是说存在更通用的方式？
Like, the way our team operates has our own ways that we like to communicate, or is there a broader way to do it?
这会不会像一个缺陷跟踪系统？
Is it something like a issue tracker?
如果你愿意就此展开聊聊，这就是一些想法。
Just thoughts if you wanna riff on that.
我觉得还待定。
I think TBD.
我们还没有以一种通用的方式解决这个问题。
We have not figured this out in a general way.
我认为，尽可能让代码和流程保持一致，会带来很大的优势。
I do think that there is leverage to be had in making the code and the processes as much the same as possible.
如果你认为代码就是上下文，代码就是提示，那么从代理行为的角度来看，能够直接查看 x y z 目录下的包会更好，而无需深入到 ABC 目录的深处，因为它们结构相同、使用相同的语言，内部模式也一致。
If you think that code is context, code is prompts, it's better from the agent behavior perspective to be able to look in a package in directory x y z, and it not to have to page so deeply into directory ABC, because they have the same structure, use the same language, they have the same patterns internally.
这种同样的优势来自于统一一套技能，让每位工程师的偏好都融入其中，以确保代理的有效性。
And that same, like, leverage comes from aligning on a single set of skills that you're pouring every engineer's taste into to make sure that the agent is effective.
在我们的代码库中，我认为一共有六种技能。
So, like in our code base, we have, I think, six skills.
就这些。
That's it.
如果软件开发流程中的某个环节没有被覆盖，我们的第一选择是将其编码到现有的技能集合中，这意味着我们可以更低成本地调整代理行为，而不是改变人类操作者的行为。
And if some part of the software development loop is not being covered, our first attempt is to encode it in one of the existing set of skills, which means that we can change the agent behavior more cheaply than changing the human driver behavior.
是的。
Yeah.
你们有没有尝试过让代理改变自己的行为？
Have you ever have you experimented with agents changing their own behavior?
我们做过。
We do.
是的。
Yeah.
一个父代理改变子代理的行为，或者类似的东西。
A parent agent changing a sub agent's behavior or something like that.
我们有一些技能蒸馏的模块。
We have some bits for skill distillation.
例如，你可以用Codex做一件很巧妙的事：直接让它查看自己的会话日志，然后让它告诉你如何更好地使用工具箱。
So, for example, there's one neat thing you can do with Codex, which is just point it at its own session logs to ask it to tell you how you can use the tool belt.
更好地使用它？
Use it better?
这就像自我反思。
It's like Introspection.
你让它
You ask
做得更好。
it to do things better.
所以更好地组织这次会议。
So Organize this session better.
我应该具备哪些技能？
What skills should I have?
是的。
Yeah.
我喜欢这种修改方式：你可以直接让代理去做事情，而不需要做其他操作。
I like the modification of you can do just do things to you can just ask the agent to do things.
对。
Yeah.
你可以直接用Codex来处理事情。
You could just Codex things.
这就像我们有一个很傻的表情符号。
This is like a this like a silly emoji that we have.
对吧？
Right?
你可以直接用 Codex 做事情。
You can just Codex things.
你可以直接通过提示来完成任务。
You can just prompt things.
这是一个你所生活的辉煌未来。
It's glorious future where you live in.
但好吧。
But okay.
你可以一对一地做，但我们实际上是在把这些内容全部收集起来，存入 Blob 存储，并每天运行代理循环，分析整个团队在哪些方面可以做得更好，并将这些反馈反映到代码库中。
You can do that one on one, but we're actually slurping these up for the entire team into Blob Storage and running agent loops over them every day to figure out where as a team can we do better, and how do we reflect that back into the repository?
是的。
Yeah.
但每个人都能免费从他人的行为中获益。
Though everybody benefits from everybody else's behavior for free.
PR 评论也是同样的道理。
Same for like PR comments.
对吧？
Right?
这些都是反馈，表明编写的代码偏离了良好的标准。
These are all feedback that means the code as written deviated from what was good.
PR评论、构建失败，这些都是信号，表明代理在某些时刻缺乏上下文。
A PR comment, a failed build, these are all signals that mean at some point, the agent was missing context.
我们必须弄清楚如何
We gotta figure out how to
是的。
Yeah.
把这些信息收集起来并重新注入到重启流程中。
Slurp it up and put it back in the reboot.
顺便说一下，我就是这样做的。
By way, I do this exactly.
对吧？
Right?
我以前用Cloud Code做房贷工作的时候。
I used to when I use Cloud Code for mortgage work.
Cloud Code这个产品挺不错的。
Cloud Code Work is, like, a nice product.
对吧？
Right?
是的。
Yes.
而且而且
And and
我觉得你会同意的。
I I think you would agree.
我总是让它告诉我下次怎么做会更好，这就是元编程的反射机制。
I always have it tell me what do I do better next time, and that's the metaprogramming reflection thing.
所以几乎可以认为，你在Symphony中有六个反射提取层级。
So almost think, like, you have six reflection extraction levels in Symphony.
几乎像是零层，这六个层级分别是策略、配置、协调、执行、集成和可观测性。
Almost like the zeroth layer so the six levels are policy, configuration, coordination, execution, integration, observability.
我们之前已经讨论过其中几个。
We've talked to about a couple of these.
但零层就像是：我们工作得还行吗？
But the zeroth layer is like the okay.
我们工作得还行吗？
Are we working well?
我们能改进我们的工作方式吗？
Can we improve how we work?
是的。
Yes.
我能不能用 RDMD 之类的东西修改自己的工作流程？
Can I modify my own workflow with RDMD or something?
我不知道。
I don't know.
当然。
Of course.
对。
Yeah.
当然，你可以。
Of course, you can.
这个东西也能自己创建工单，因为我们给了它完全的访问权限。
Like, this thing is also able to cut its own tickets because we give it full access.
是的。
Yeah.
让它创建一个工单来自动处理其他工单，你可以在工单里注明预期的后续工作。
Make it a ticket to have it cut tickets, you can put in the ticket that you expected to file as on follow-up work.
像自我修改一样。
Like Self modifying.
对。
Yeah.
关于 Bayt 播客
Bayt 提供中文+原文双语音频和字幕，帮助你打破语言障碍，轻松听懂全球优质播客。