异步代理时代——Cognition的颜 Walden 与 OpenInspect 的 Cole Murray

没错。

to Yeah.

正是如此。

Exactly.

有很多看似微小的细节，其实对最终的合并效率影响很大。

There's a surprising long tail of small details that ends up making a big difference for this kind of end metric of like how fast do you actually merge the code in.

我们早期花了很多时间打磨的一个体验，就是这些工具在 GitHub 上该是什么样的使用感受。

One experience that we spent a lot of time tuning early on was what is the right experience on GitHub for these tools?

当然。

Sure.

我觉得现在大多数工具，当你开发智能代理时，通常只会想到：它能帮你创建拉取请求。

Because I think most tools out there, when you build the agent, you'll think about, oh, like it will create the PR for you.

我们更进一步，直接想：如果我们能让用户直接在 GitHub 上和 Devin 互动，会怎么样？

Try to take that a step further and say, oh, like, what if we actually made sure you could interact Devin with Devin directly on GitHub?

所以我们确保了你可以在 GitHub 上留言，Devin 能收到并回应这些评论。

And so we made sure that you can comment on GitHub and Devin would actually receive those comments and address them back.

但这里其实需要做不少调整，比如我们最近上线了 Devin Review 功能。

But there's actually quite a bit of tuning you have to do here because you can imagine that actually, like, we recently have Devin Review, for example.

Devin Review 会在自己的 PR 下面留言，然后 Devin 又得去处理这些留言。

Devin Review will post comments on his own PR and then Devin has to then go

它自己回复自己的评论，这简直是个循环。

He answers his own comments, which is really loopy.

我喜欢它在这里直接更新，提醒我有人评论了。

So, like, yeah, I like that it just updates here that it's that I have commented.

但通常我就是说一句：嘿，合并前解决下冲突。

But usually it's just me saying like, hey, merge fix any merge conflicts.

对。

Yeah.

当 Devin 修复自己留下的评论时，你可能会担心陷入无限循环，但我们花了很多精力避免这种情况——不仅确保评论有足够价值，还让代理能分辨哪些评论值得立刻修改，哪些得先想想：等等，你可能搞错了。

So when Devin fixes its own comments, you might be scared that it'll look maybe I'll infinite loop, but we've put a lot of work into making sure it doesn't, both by making sure that the comments are high signal, but also that the agent is thoughtful about what comments that immediately goes and tries to fix and what comments is like, Wait a second, I think you're wrong.

其实我最喜欢的就是 Devin 告诉我我错了的时候。

Actually, that's one of my favorite moments is when Devin tells me that I'm wrong

当我

when I

试图做点不一样的事情时。

try to get to do something different.

是的。

Yeah.

但调整这种行为，确实会大大影响你的使用体验。

But tuning that behavior, like, actually makes a big difference in terms of how you just will get up experiences.

对。

Yeah.

没错。

Yeah.

我觉得还有一点值得提，那就是把AI评审员整合进系统，是这套后台机制的关键部分。

I think to touch on that as well, I think having the AI reviewer integrated into the system is a critical part of this background system.

OpenInspect 就做到了这一点。

OpenInspect does have that.

它内置了一个 GitHub 代码审查工具，你可以自定义提示语。

It has a GitHub code reviewer that you can control the prompt.

它也能生成评论。

It does do comments as well.

不过目前还不会自动执行。

It doesn't do them automatically yet.

功能是有的，只是还没完全上线。

The capability is there, but it's not fully

所以大家都会主动要求使用吗？

So guys ask for it?

当然会。

Oh, you do.

是的。

Yeah.

你可以在 GitHub 上标记一下，然后你给那个机器人起的名字，它就会自动跟进。

You can tag it on GitHub and then whatever you named your GitHub bot, it will then follow-up on it.

如果你有合并冲突，或者你让它处理的其他问题，它就会自动解决。

It will then if you have merge conflicts or whatever you have asked it to resolve, it will then resolve it.

但它现在还不能全自动完成。

But it doesn't do it automatically yet.

我很好奇，当你们帮客户部署OpenInspect时，他们最常提出哪些额外需求？

Well, I'm curious, what is the most common thing that people end up requesting that they still need on top of OpenInspect when you help them go implement it?

我觉得很多问题其实出在如何把它融入公司体系里。

I think a lot of it comes down to actually integrating it into the company.

搭建后台代理系统是一回事，但如果它没法真正接入你们的整体系统，用处就有限。

It's one thing to kind of have the background agent system set up, but if it isn't actually integrated into your larger ecosystem, it isn't that useful.

当然，能手动启动会话还是有帮助的。

I mean, it is useful to be able to kick off sessions.

但我们真正想做的是把它接入所有其他系统，比如只读权限的生产数据库、日志系统，或者Confluence这类内部知识库。

But what we really want to be able to do is hook it into all of our other systems, whether that is the production database with read only credentials, the logs, a confluence or internal knowledge based system.

我觉得这才是企业真正能实现飞跃的地方。

I think that is where I see the huge leap for companies.

这对一些公司来说也可能是个挑战，尤其是当他们不太清楚该怎么下手的时候。

And that can be a challenge for companies as well who are maybe not familiar with exactly how to approach it.

特别是那些身处合规要求严格、权限控制特别重要的环境中的公司。

Especially if they're in environments that have more compliance type things where access control can be pretty big.

那你怎么有意识地去思考这些问题呢？

And how do you deliberately think about these problems?

我觉得这正是这类系统常会带来的一个难题。

I find to be kind of one of the problems that comes with a system like this.

是的。

Yeah.

我们发现，MCP确实引发了很大的热潮，大家都说能跟各种系统集成。

The thing we've found is so, like, MCP is obviously, it has been a really big explosion of, oh, you can go integrate it with all these different things.

但真要做得到位、体验好，我们往往得自己临时搭一些解决方案。

But to actually get the integration right and get the right experience, oftentimes, we found out we had to go build our own ad hoc things.

比如Slack就是一个很好的例子，你可以给你的代理配个Slack的MCP，这样它就能在Slack上给你发消息。

Think Slack is a great example of Like, you could give your agent a Slack MCP and, okay, you can post messages back to you on Slack.

但我们实际上是把Devin当成了Slack里的一个同事，从一开始就按这个思路设计的。

But we actually use Devin like a coworker in Slack and that's how it's been built from the ground up.

但要做到这一点，你得支持双向的Webhook，对吧？

But to do that, you actually need to support webhooks that come back, right?

然后Devin得用自然的方式回应，还得别在对话线里刷屏惹人烦，这体验得调得刚刚好。

And then Devin has to respond in a natural way and then hopefully don't spam your threads too much and annoy the people in your company, so you gotta tune that experience just right.

尤其是，来回互动特别多。

Especially, there's a lot of back and forth.

我们发现，在这些地方，光靠简单的MCP集成根本不够。

Like, we find that we actually had to go beyond the simple MCP integrations in these places.

我刚去看了下MCP市场。

I just pulled out the MCP marketplace.

我知道这活儿真不轻。

I know this is a fair amount of work.

我的意思是，最终是不是得自己掌控所有主流的MCP？

I I mean, is is the answer to eventually take first party control of all the top MCPs?

就是说，是不是这样

Like, is that the

我真希望有个世界，能有一种比MCP更丰富的系统

I would love a world where you could have something that's more expressive than MCP.

不只是提供一组工具，而是一个能双向互动的完整系统，跟各种界面自然地配合

That kind of like goes both ways, like not just a set of tools but like a proper system that interacts back and lets it have the right experience with all these interfaces.

MCP规范里其实有采样功能，但没人用，对吧？

So, there actually is sampling in the MCP spec but nobody Right?

都没人用

Uses

我觉得另一点是，当MCP规范变得太复杂时，它原本那种‘一键连接’的简单承诺就慢慢没了

so, I think that's the other part is like actually we found that when the MCP spec starts to get too complicated, it starts to lose its original promise of being like a simple one step connect.

现在我们反而得花力气去适配各种不同的版本，很多情况下，看起来就跟直接开发专属集成没什么区别了

Now, then we have to go figure out how to support all these different variations of things and it starts to look a lot like just building their first party integrations in a lot of use cases now.

对

Yeah.

我觉得这还跟它对公司有多关键有关，对吧？

I think it matters too how critical it is to your company, right?

如果几乎所有会话都要经过这个环节，那最好还是自己掌控，这样能在此基础上做优化。

If this is something that nearly every session is going through, it probably makes sense to own it so that you can make optimizations on top of it Yeah.

而不是随便用个现成的方案。

Versus just whatever is off the shelf.

对。

Yeah.

太好了。

Awesome.

其他MCP呢？还有哪些？

Other MCP's, what else?

抱歉。

Sorry.

不过，我怕我们把重点太局限在集成上了。

Well, I don't know if that's narrowing in too much on integrations.

那还有别的吗？

But what else?

比如，你们在构建 OpenInspect 或 Devin 时，还特别注重哪些方面？

Like, what other elements of building OpenInspect or Devin that you guys really sync on?

是的。

Yeah.

我经常遇到的一个问题是关于记忆或者知识库的处理。

I think a problem that comes up very frequently is this idea of memories or knowledge base.

天啊。

Oh, boy.

没错。

Yes.

你们是怎么解决的？

How do you solve it?

简短的回答是：还没解决。

So not solved yet, is a short answer.

嗯，是这么回事。

Uh-huh.

这个问题已经有开放的议题了，有人在问。

It's something there's a open issue for it, someone asking about it.

明白了。

Okay.

目前我的知识库还没收录任何关于记忆的内容。

There's I I d wiki hasn't indexed anything about memory yet.

我看到客户们主要通过技能来解决这个问题。

How I'm seeing it solved across my clients is primarily through skills.

我发现技能可以弥补这方面的不足，或者用来更新Claude MD。

I find that skills can be a good gap within that or updating Claude MD.

但整体来看，记忆仍然是个没解决好的问题，这也是我迟迟不敢加入它的原因。

But I think memory as a whole is a pretty unsolved problem and it is why I've been kind of hesitant to add it.

当然，记忆的某些部分还是可以处理的。

I think there is parts of memory and that can be addressed.

但总的来说，这是一个非常难解决的检索问题。

But I think as a whole, it's a very difficult retrieval problem.

天哪。

Oh my god.

确实如此。

Yeah.

Ramp 没有写过任何关于内存的内容吗？

Ramp didn't write anything about memory?

我搜出来零结果。

I see zero search results.

内存的实现其实挺难把握的。

Memory can be quite tricky to get right.

因为不仅检索困难，生成内存内容也很有挑战性。

Because it's the retrieval, but also the generation of the memory is that can be really tricky.

你可不希望它只是随便回应一下。

Like, you don't want it to just Yeah.

就是说，不管什么特别具体的数据。

Like, okay, whatever very specific data.

给我们讲讲Devin的记忆发展历程吧，我知道这中间经历了不少变化。

Walk us through the Devin memory journey because I know there's been a journey.

最早那个一直沿用了一段时间的记忆系统，我们叫它‘知识库’。

The first version of memory that kind of like stuck around for a while was a system we have called Knowledge.

对。

Yeah.

我们的想法是，希望它能慢慢积累经验，不需要用户每次都主动去教Devin。

And the idea was we wanted it to pick up things over time and not need the user to be proactive about teaching Devin things.

每当你提醒Devin：等等，你这样用Git不对。

So, anytime you remind Devin, wait, no, that's not quite the way you're supposed to use Git.

我们其实希望Devin能主动问：你要不要我记下这个，以后遇到类似情况直接提醒你，你只需要快速确认或否决就行，让它慢慢积累起来？

Like, we actually want Devin to say, hey, do you want me to actually just remember this for the future and for you to just basically quickly approve or reject and for it to build up over time?

因为我发现，大概95%的Devin记忆，都是通过这种自动生成的方式积累下来的。

Because I find that, like, 95%, I think, some crazy style like that of the memories that Devin has are all through these auto generated things.

实际上，很少有人愿意坐下来写大篇幅的文档，说明该怎么使用这项技术之类的。

Like, very few people actually just want to sit down and write big docs on, okay, here's how you're supposed to work with the technology, etcetera.

生成和检索这一块，我们这些年一直在不断调整。

The generation in the retrieval has been something that we've been trying to tune a lot over the years.

生成的时候，你当然不希望它记住了某一次的请求，比如‘请把这次改成草稿PR’，就从此以后所有人都得用草稿PR。

Generation, like, you don't want it to remember something like like if you asked one time to like, oh, please open it as a draft PR.

你不想让系统觉得，从此以后所有PR都得是草稿状态。

You don't want be like, oh, everyone forever now should get their PRs as draft PRs.

但你确实希望它能记住一些普遍的规律，比如某种常见的做法。

But do want some kind of common beer maybe you want to say.

比如说，科尔通常喜欢把东西创建成草稿PR。

Like, oh, Cole generally likes things to be created as draft PRs.

检索也是同样的道理。

Same with retrieval.

如果你有成千上万条记忆，该怎么确保它们在恰当的时候被调出来呢？

Like, you know, if you have thousands of these memories, how do you actually make sure they're retrieved at the right time?

要做得好而不让大量无用信息撑爆上下文，其实挺棘手的。

And that can be quite tricky to do right without exploding the context of a bunch of useless information.

光是做评估工作，就得花不少功夫，才能确保记忆系统在新模型不断更替时依然可靠。

Surprising amount of just like eval work to just make sure that like memory remains a reliable system as new models come and go.

对。

Yeah.

你有没有什么可以分享的，关于怎么清理记忆的？

Do you have anything that you could share around like memory pruning?

有。

Yeah.

还有就是记忆的时间维度问题。

Then like kind of the temporal aspect of memory.

没错。

Exactly.

对。

Yeah.

现在，它们能做的事情之一就是修改记忆。

Today, the so the things they could do is it could edit memories.

原来如此。

I see.

假如以前的记忆记录说，Cole 喜欢把所有东西都当成草稿 PR 提交，那你可以告诉它：别这样了。

And so if your memory used to say like, oh, Cole likes to open everything as like a draft PR, then you can imagine, no, don't do that.

然后它就会问：要不要把记忆更新一下，改成 Cole 现在的做法？

Then it'll say, oh, do you want me to update the memory to be Cole now?

我希望所有东西都直接作为 PR 提交。

I want everything as, you know, open PRs.

我觉得，我们现在这个系统可能还不是最终版本。

I think that at the same time, we don't know if this is gonna be the final version of the system.

不管现在有什么，大概都会被整合进我们接下来要开发的新系统里。

Whatever we have here will probably translate into the new system that we'll be coming up with.

但我觉得，和两年前相比，最大的不同是，现在的智能体已经非常擅长直接使用类似文件系统的东西了。

But I think one big difference between two years ago and today is these agents are really good at using anything that resembles a file system natively.

所以我们也在想，要不要把记忆系统重新设计成更像文件系统，让代理自己去浏览和操作？

And so part of us is thinking, oh, should we rebuild memories to feel more like a file system that we let the agent navigate on its own?

这个想法挺有意思的，我们一直在探索。

That's been an interesting exploration.

另外，在技能方面也有一些新的想法。

Also, some ideas in in the skill space.

我现在正在打开 OpenClaw 的记忆系统。

I'm pulling up OpenClaw's memory thing right now.

你看，OpenClaw 的记忆里有个类似每日日记的功能。

So memory OpenClaw has like this, like, daily memory journal thing.

对吧？

Right?

你可以通过它来查阅，它确实是一个可信的信息来源。

And you can I mean, that is a false system you can kind of grab through and is a source of truth?

不过我不确定这是否是最好的方案。

I don't know if it's the best.

这 probably 会特别杂乱。

It's probably super noisy.

但至少如果你丢了什么，还能找回来，或者用某种遗忘机制，把那些很久没被调用的旧记忆清理掉。

But at least if you lose something, you can discover it or you can apply some kind of forgetting algorithm to, like, more ancient memories that don't get recalled again or something.

我们一直在尝试突破公司里使用智能体的方式，就是让智能体拥有类似文件一样的记忆。

One thing we've been trying to do to push the boundaries of how you use agents at your company is letting an agent basically have a very similar file, like a memory.

比如一个 Markdown 文件，让它长期担任某个特定问题的专属项目经理。

Md or something, and just kind of like be your permanent PM for a specific set of issues maybe.

可以在公司内部建一些 Slack 频道，比如专门为 DeepWiki 这类产品开一个专属频道。

So, have like some Slack channels internally, maybe a Slack channel dedicated to a specific product like DeepWiki maybe.

你可以想象，有个 Devin 永远在线，从不休息，但它会维护一个自己的记忆文档，记录当前最该解决和优先处理的事项。

And you can imagine that you want a Devin that never stops, it's just always awake, but it has this memory doc that it can just maintain for itself about, okay, what are the number one priorities of what we have to fix and prioritize?

谁负责接下来的哪些任务？

Who is responsible for some upcoming work?

它甚至可能定期给你发提醒，@你一下。

Maybe they'll even tag Devin will even tag you on some recurring basis.

是的

Yeah.

所以，我们一直在探索，怎么才能让Devin的应用超出工程范畴。

And so, it's been an interesting move to see, okay, how can we actually use Devin for more than just engineering?

我们能不能把Devin的使用往上延伸，超越工程流程本身？

Can we actually upstream, above the engineering process?

也许Devin只是创建一些任务单，这些任务单可能由人类来处理，也可能由其他Devin来接手。

And maybe it's just Devin creating tickets, which then maybe some humans do, but then maybe other devons do.

对。

Yeah.

我最有趣的一个自动化设置是，让它定期研究竞争对手，然后每周给我提一些建议。

One of my more fun automations is go research competitors and just suggest stuff to me on a weekly basis.

这就是那个自动化流程。

That that's that's the automation.

我现在一时找不到了。

I can't find it right now.

但本质上就是去研究竞争对手，然后给出一些建议。

But basically, just like look at competitors and suggest things.

当然。

Sure.

这是你之前推荐过、但我现在不想要的三样东西，你可以直接把这些加进提示里。

And here are three things that you suggested that I don't want anymore of, and you just kinda stick that in the prompt.

不过，确实如此。

But like Yeah.

我其实希望，比如当我拒绝一个合并请求时，系统能自动更新记忆，这样我就不用再回头去调整排定的同步任务了——这已经是个功能请求了。

I wish actually so for like when I for example, when I reject the PR, I I wish that it updated memory so that I can then just not have to go up, go back and update the scheduled sync, but they came out, feature request.

我们可能很快就会改。

You know, we might change it soon.

你在使用OpenInspect这段时间里，有没有试过实现某个功能，结果后来不得不推翻重来？

I I guess OpenInspect, in the time you've been around, has there been anything you tried to implement, which then you had to like undo and like do a different way?

目前还没有，不过我脑子里倒是有个想法。

Nothing yet, but something that is on my mind.

我最初的设计是，每个集成都作为一个独立的包存在。

The initial way that I built it was that each of the integrations kind of lives as its own package.

比如 Slack 机器人负责处理 Webhook，然后它和控制平面进行交互。

And so you have the Slack bot, which is what's handling the webhooks, and then it's basically interacting with the control plane.

随着系统越来越集成，特别是 GitHub 机器人这一块，我正在考虑把所有功能都整合到中央控制平面里，因为现在我收到的需求是，不仅要跟踪拉取请求的状态，还想监控哪些 PR 被合并了。

As I'm seeing the system starting to be more integrated, specifically with the GitHub bot integration, I'm considering bringing that all into the central control plane because especially now I want to start a request that I'm getting is the ability to monitor the actual pull requests being merged as well as just kind of tracking of

我现在有哪些是打开的？

Like what do I have open?

是的。

Yeah.

我现在有哪些是打开的？

What do I have open?

有多少个正在被合并？

How many of these are getting merged?

有多少条评论出现了？

How many comments are showing up?

只是为了了解系统的整体运行状况。

To just kind of understand the health of the system.

对于 GitHub 应用来说，你只有一个 Webhook。

And so in the case of a GitHub app, you only have one webhook.

所以问题来了，我是把这个 Webhook 放在 GitHub 机器人这个包里吗？

And so then it's a question of, do I put that webhook in that GitHub bot package?

这样有点奇怪。

That's kind of weird.

它根本不该待在那里，因为那个包主要是给代码审查用的。

It doesn't really make sense to live there because that package is more for the code reviewer.

还是说，我该把它集中到中央系统里？

Or do I centralize it?

这正是我现在在考虑要做决定的事情。

So that's something that's on my mind of making that decision.

我想我们之前也提到过另一个问题，就是内置还是外置的方案。

I think the other one we touched on earlier is the harness in the box versus out of the box.

我觉得从长远来看，这个架构最终还是会回归到开箱即用的设计。

I think long term, the architecture will eventually come back out of the box.

我最近加的一些新工具会回传数据到控制平面，这样就不必把密钥留在沙盒里了。

Some of the newer tools that I've added are calling back into the control plane so that you don't have the secrets in the sandbox.

所以长远来看，我大概会把实际的代理模块移出沙盒。

And so I think long term, I probably will pull the actual agent out of the box.

但现阶段，我觉得这样挺有意思的。

But I think for now, it's fun.

关于把代理移出沙盒，我有个小问题。

Just a quick question on pulling the agent out of the box.

今年我特别看好代理之间互相调用、创建子代理这类做法，不管你怎么称呼它。

I I one thing I'm very bullish on this year is agents calling other agents or spawning sub agents or whatever you wanna call it.

对。

Yeah.

这会让事情变得更难还是更容易？

Does that make it harder or easier?

我说不准。

I can't tell.

因为如果工具链在盒子里面，你就可以多开几个盒子。

Because if the harness is in the box, you can spin on more boxes.

对。

Yes.

如果工具链在盒子外面，那就没那么方便了，因为你得养个像独角兽一样的工具链，它还偏偏住在盒子外面。

The harness is outside the box, then you're it's less easy because you are you have a, you know, a unicorn pet of of a of a harness that's like living outside the box.

我的意思是，理论上应该是这样。

I mean, in theory, it would

情况也是一样的。

be the same way.

对吧？

Right?

不管是一个代理启动了多个子会话。

Whether one agent has launched many sub sessions within it.

比如 OpenInspect，它可以启动子会话，创建其他环境并进行监控。

OpenInspect, for example, can launch sub sessions and actually create other environments and then monitor them.

如果是在盒子外面，那就只是多了一个正在运行的会话而已。

In the case where it is out of the box, that would basically just be an additional session that's running.

所以这个会话也是在盒子外面运行的。

And so that session is also running outside of the box.

它运行在你的工作节点上，也就是你部署这个系统的地方。

It's running in your worker plane, wherever you're running this.

然后你得仔细想想，顶层代理该怎么和它交互。

And then you really just have to think about how does your top level agent then interact with it.

我觉得这确实会更复杂，因为架构本身变得更难处理了。

I do think it can be more complex just because, again, you have now a more difficult architecture.

但如果你能搞定一次，之后应该就没什么问题了。

But I think if you figured it out once, it's probably fine.

对。

Yeah.

Walden，我想听听你的看法，我管这个叫元Devin管理。

Walden, I'm just throwing it open to you in terms of like I I call this kinda like meta Devin management.

对。

Yeah.

就是Devin调用Devin、安排Devin任务、查询轨迹之类的，你们有没有开发或上线过什么相关的东西？

Which is like the Devin's calling Devin's or Devin's scheduling Devin's or querying trajectories or anything like that, what have you built or unshipped anything?

我们发现一个挺意外的现象：这些独立代理之间协作、希望它们并行工作的方式，大多还是沿用了传统的主代理-子代理模式。

I think one of the surprising things we've seen is that a lot of the ways that these separate agents work with each other and you want them to paralyze their work has still mostly followed the same manager sub agents regime.

很多人其实很期待一个由大量代理组成的生态，它们能随时随地互相沟通。

And a lot of people, I think, are excited about this world where you have swarms of agents that kind of, you know, talk with each other all over the place.

我们确实给Devin接入了MCP，让它能随意给其他Devin发消息、创建新的Devin等等。

We've actually given Devin an MCP so they can just go arbitrarily message other Devin's and create new Devons, etcetera.

但这样一来，整个系统反而变得特别混乱。

But I guess it somehow creates a really chaotic world in that sense.

所以到目前为止，日常实际使用中，我们发现最有效的还是单个事件驱动的模式。

And so we've still found that most practical use on a day to day basis has been one single event.

是的。

Yeah.

关键是要把任务合理划分开，让其他Devin各自在独立的环境中工作，不共享机器。

Figuring out how to segregate the work and get have other devons work on it in like a relatively isolated sense, each with their own boxes, not sharing machines.

所以目前我们不得不建立一种机制，尽量减少冲突的可能性。

So there's like a very little room for conflict is kind of the regime that you have to create today.

我得提一下Cursor的那些实验。

I'll call out the experiments from Cursor.

对吧？

Right?

这是林伟森在单智能体转向多智能体方面的研究。

This is Wilson Lin's work on single agent to multi agent.

你一向主张别搞多智能体系统，但他们折腾了一圈，最后得出的结论，跟Devin的做法几乎一模一样。

And you're obviously famously on this side of don't don't build multi agent, but they went through the whole thing only to arrive at this, which is exactly what Devin has, I think.

我觉得过段时间，那篇文章可能会被修订。

I think there will be a revision to that post at some point.

好的。

Okay.

说说看。

Tell us about it.

一年前，大家还认为多智能体根本不可能实现。

Think multi agents were very much not at all possible a year ago.

现在确实能看到更多多智能体的实验，但你也可以质疑，这些真算得上多智能体，还是只是工具调用？

You do see more multi agent experiments today, but you can kind of argue, are they really multi agents or are they just kind of just like tool calls?

比如有人会创建子智能体去查找某个文件或某个代码实现。

You know, like there are people who will create sub agents to go look for XYZ file or XYZ implementation.

这样做的好处是上下文管理很清晰，所有工具调用和消耗的token最终都会汇总成主智能体的一个答案。

Has really nice context management benefits because all of the tool calls and tokens that it spends then get collapsed back to just the answer for the main agent.

这么做确实有很多优势。

There's lot of benefits to doing this.

我们基本上让Devin这么做，调用Deep Wookie，然后把结果返回给你。

We basically have Devin do this with Deep Wookie, make a call out to Deep Wookie, give you back the results.

但这感觉更像是一个工具调用。

But that feels like a tool call.

你明白我的意思吧？

You know?

这并不是两个协作方在真正地来回交流。

It's not like these two collaborators actually talking back and forth with each other.

但我觉得最让我相信多智能体真的可能实现的，是我之前提到的，Devin 有时候会直接告诉我我错了，还会跟我争辩。

But I think the thing that gives me the most bullishness that multi agents might actually be possible is actually what I said earlier about Devin will actually sometimes tell me I'm wrong and push back.

我认为这说明现在的智能体在沟通上已经达到了一定的成熟度，让多智能体系统成为可能。

And I think that demonstrates a level of maturity in communication today that makes a multi agent world possible.

比如，当两个看到不同信息的智能体重新碰头时，

Like, when can two agents who have seen different information come back to each other

它们能不能真正判断出谁是对的，到底该

and actually figure out who is right, what what

采用哪种实现方式？

is the correct implementation?

他们可不是只会附和的应声虫。

They're not just, you know, yes men.

克劳德以前大概总是说，嗯，到底是什么呢？

Claude, I guess, is like used to just say, like, you know, what is it?

你说得对，或者

You're you're right or

你完全正确。

You're absolutely right.

你完全正确。

You're absolutely right.

是的。

Yeah.

是的。

Yeah.

你有看过吗？你看到没？

The have you seen Did you see

Codex

the Codex

App Troll 和 Topic？

app Troll and Topic?

这是 Codex 应用。

This is the Codex app.

在设置里有个小彩蛋。

Inside of settings, there's a little there's a little Easter egg.

对吧？

Right?

如果你去那里，比如主题或者外观设置那里。

So if you go there, like, their their themes or appearance.

对吧？

Right?

里面一堆颜色代码，顶部用的完全是 Anthropic 的配色，这简直是在恶搞。

There's all these, color codes and the top is absolutely and it's Anthropic's colors, which is such a troll.

好了。

Anyway.

我超喜欢这个彩蛋。

I love that Easter egg.

这个是你自己发现的吗？

Did you discover that yourself?

不是。

No.

是有人在推特上提到这个，我就想，这真的假的？

It was like someone someone was tweeting about it and I was like I was like, is this true?

因为有时候人们发帖就是故意激你一下。

Because like sometimes people just tweet stuff to get a rise out of you.

不过是真的。

But yeah.

就是这样。

There you go.

Anthropic 的配色

Anthropic colors.

是的

Yeah.

但确实，我们现在已不再处于那种只会简单附和、无法进行真实对话的阶段了，它们能进行真正有来有回的交流。

But, yeah, we're we're we're out of this regime where, you know, it just says you're absolutely right and they can have real conversations and real back and forths.

是的

Yeah.

你也可以特意引导它，让它表现得更具对抗性，或者别的风格。

You can prompt it as well to be more adversarial or whatever.

是的

Yeah.

明白了

Okay.

是的

Yeah.

在我看来，这才更像智能，对吧？

To me, that is more intelligence, right?

这可不是什么傻乎乎的工具，它真的会跟你对抗、跟你较劲。

Like, that is not just something that's like a dumb tool, it's actually pushing back on you.

是的。

Yeah.

没错。

Like, yeah.

你提到那个问答博客的时候，我记得他们做过一个实验，让一群智能体协作，真给搭出了个浏览器。

When you mentioned the question blog posts, there was one blog they had where they fed a swarm of agents together and built a browser.

对。

Yeah.

是的。

Yeah.

应该就是那个案例。

That that was I think that was the one.

你可以让

You can have like

我觉得就是同一个。

I think it's the same one.

对。

Yeah.

我们发现一个意想不到的成功案例：根本不用搞什么群组。

We found a surprising success of like, don't do a swarm or anything.

就用一个Devin就行，你知道的，它自己就能管理上下文。

Just have one Devin, you know, it does its own context management.

让它持续运行一段时间，给它一些疯狂的任务。

Just let it keep running for a while and give it some crazy tasks.

我记得我们让它重新构建一个Windows操作系统。

I think we asked it to rebuild a Windows OS system.

没错。

Yes.

它还真完成了，就是坚持了足够长的时间。

And it managed to do it, just like, you know, going on for long enough.

这是安德鲁的那个项目吗？

Was this Andrew's thing?

是的，没错。

Yeah, yeah.

好的。

Okay.

我们其实做了很多演示，但最后都没发，因为那时候发得太多了，全是些最终成果的展示。

There were lots of demos that we ended up not posting because at some point we'd just be posting way too much a bunch of end of demos.

但我特别喜欢这一点，因为它说明多智能体系统还是有种让人兴奋的魅力，这种魅力可能超出了它实际为系统带来的能力提升。

But I love that because it kind of shows that I think the multi agent thing it still has like a bit of exciting sexiness to it, which is maybe still beyond still like the actual delta it adds to the capabilities of these systems.

但这绝对是未来的发展方向。

But it's absolutely the future.

我觉得我们正朝着这个方向走，而且已经能看到明显的进展了。

I think we're, you know, we're heading that direction and we can see the progress being made there already.

是的。

Yeah.

如果我要提一点小小的不同意见，是因为我还没完全确信，但我之前请过OpenInsurf的瑞安·洛波普洛上过我们的播客，他可是个顶尖高手。

If I were to make one super minor pushback because I don't feel that confident about it yet, but I've I've had Ryan LoPopulo from OpenInsurf on on the pod and he's a super slob canon.

对吧？

Right?

天哪。

Oh my god.

我的编程代理已经搞定了。

That's my coding agent being done.

我下载了这个叫PYON ping的工具。

I I I downloaded this like PYON ping.

不知道你们有没有听说过。

I don't know if you guys have heard this.

它会从《命令与征服》《魔兽》这些热门游戏里提取音效包，一完成任务就自动播放出来。

It it takes like sound packs from popular games like Command and Conquer and like Warcraft and then it plays it whenever it's done.

比如工作时的指令之类的。

Like work, work or whatever, like at your commands or something.

总之，从光标代码库和瑞安的做法里，我了解到一种‘插槽式代理’的思路，就是想打破单个代理的瓶颈。

Anyway, what I got from from the cursor code base and from from Ryan's thing was that there's a slot canon approach where you try to loosen the single agent's bottleneck.

我觉得这事儿特别重要，值得好好研究一下。

And I feel like that is like probably a very important thing to try to figure out.

但我觉得还没人真正解决，因为那样的话，你只是在代理的瓶颈上又堆了一层审核机制，更难管了。

I don't think anyone's like really solved it because then you just have more reviewer stop on top of the agent stop to to try to wrangle it all.

瑞安肯定强烈反对我说他没解决这个问题，他觉得自己已经彻底搞定了。

Ryan will probably very strongly object that I I say that he hasn't solved it, but he thinks he's he thinks he's completely solved it.

但我觉得这依然很关键，毕竟这确实是个瓶颈。

But, like, I think it's still I think it's, like, very important because, like, that is a bottleneck.

对吧？

Right?

我觉得德文有时候太慢了，明明代码写得挺清晰合理，但效率上不去——我真希望有个按钮，能直接把并行度拉高一千倍，看看结果会怎样。

I I feel Devin is slow sometimes because I'm like, well, yeah, this is very readable and very sensible, but also it is slower than it could be if I just like I want a button to just say, like, just ramp this up 1000x parallel in parallel and just like see what happens, you know?

我不确定将来有没有可能实现这一点。

And like, I don't know if that's like it's feasible at some point in the future.

是的。

Yeah.

我们内部也做过一些实验，试着完全靠‘感觉编程’来构建真实可用的产品，大家轮流写代码，自动合并，完全不进行代码审查。

We've also run experiments internally where we've basically tried to build entire products, like true products that we knew we would eventually ship, but for now let's try to see if we can do it just by purely vibe coding on top of each other, auto merge, no code review at all.

然后我们设了一个衡量标准：这种模式能撑多久，直到你不得不放弃整个代码库。

And then there's this kind of benchmark of how many weeks can you go onto this for before you say we have to trash this codebase.

其实你可以再从《星际迷航》里找找灵感。

Actually, reread it from Star Trek.

对。

Yeah.

你找到什么了吗？

Did you find?

我觉得去年十二月的时候，最好的情况也就是能撑两周左右。

I think we found that the state of the art in December was you could probably run this for about two weeks.

到这两周结束的时候，你会发现，嘿，你想改个按钮的颜色？

By the end of those two weeks, you'd find that, hey, you wanna change the color of a button?

结果发现这个按钮在十个地方都有实现，每个地方的样式还不一样，你漏掉了一个，颜色稍微有点偏差，就差一点。

Well, it turns out this button is implemented in 10 different places and they have all these different variations and oh, you forgot one of them and actually it's a slightly different color, one spline.

好吧，这实在没法继续搞下去了。

Okay, this is too much to work with.

我们还是得加上代码审查，及时把问题修掉，确保代码是按可扩展的方式写的。

Let's actually try to do code review at the same time and make sure that we're on top of our stuff, we're actually cleaning it up a bit and making sure it's done in a scalable way.

是的。

Yeah.

我觉得，认为不需要看代码这个想法，总体上是个错误。

I think building on that, the idea of like you don't have to look at code, I think is generally a bad idea.

我有个相关的梗是

And the the meme that I have for

什么时间线？

What timeline?

好吧。

Alright.

你觉得这句话什么时候还成立？

Is is do you think that statement will be true on?

我觉得在一段时间内，你还是得继续检查自己的代码。

I think probably for a while, it'll be true that you should continue to look at your code.

我见过很多正在采用AI优先开发方式的团队遇到一个问题：他们的代码库会越来越像最差的工程师写的。

A problem that I see a lot of teams run into that I work with who are embracing kind of AI native, AI first coding is the meme that I have is that your code base regresses to your worst engineer.

因为那个特别热衷于AI、却从不审查代码的工程师，他的写法会慢慢变成代码里的标准。

Because that engineer who is very gung ho about AI and is not auditing their code, their pattern starts cementing into the code.

现在AI都在参考这些写法。

And now the AI is referencing their patterns.

于是，那个满是二十多个if-else嵌套的代码块，

And so now their if else block that, you know, is 20 if else's back and forth.

AI就以为这是正常的写法，结果越写越乱，问题越积越多。

The AI is seeing that as the pattern of how things are done and starts to then exponentially grow the slop.

我觉得你提到的这个办法挺好的，就是定期安排清理工作，不管是人来处理，还是用系统来检测重复代码。

And I find to your point a pretty good approach to that is having scheduled cleanup, whether by humans or through systems that are looking for duplication.

然后把这些问题解决掉。

They then address that.

最后你可能会发现有十二种不同的方法来格式化日期。

You'll end up with 12 helpers for how to format a date.

这种情况必须处理，不然代码会越来越乱。

And you need to address that because otherwise it will continue to sprawl.

在合理范围内，我觉得有些重复是可以接受的，偶尔也可以做一次代码清理。

Within bounds, think it it's fine to have some duplication and then sometimes you have a garbage collection.

对吧？

Right?

没错。

Yeah.

我跟很多工程负责人聊过，他们认为模块之间的边界一定要严格把控。

The the what I've been talking about with a lot of engineering leaders is that you want to be very strict about the boundaries between modules.

作为架构师、CTO，或者任何类似角色，你的职责就是明确划定界限：你们内部怎么搞都行，那是你们的事，但在这两个团队之间，必须清清楚楚，任何跨界的改动都得经过人工审批，要么是我，要么是其他人，就这么定了。

And it's your job as an architect, as a CTO, whatever, to say like, okay, here's the hard contract between you guys and you guys, whatever you do inside this black box is your business, you do whatever, but like between these guys, let's be like really damn clear, and any movement must be signed off by a human or me, you know, then and like that's that.

我不知道你还有没有其他建议或想法。

I don't know if you have any other modifications or advice.

说到人类能发挥作用的地方，我发现有些特别复杂的基础设施问题，往往只要有一个拥有深厚经验的人介入，就能带来巨大改变。

Well, guess, generally on the topic of like where humans can be useful, I found that some of these like really deep infra problems, sometimes just having a heroine that just has really deep expertise can make a big difference.

我在开发智能代理的时候，确实见过这种情况发生。

I've actually seen this come into play when actually building agents.

现在有不少朋友在尝试构建自己的编程代理，我听很多人反复提到同一个问题：在他们的机器上，grep 太慢了。

So, we've had a few friends now try building their own coding agents and I think one same problem that I recurrently heard a lot of them run into was this problem of like, Oh, you know, grep is really slow on our agents' machines.

很多人因为主要依赖 AI，自己又缺乏深厚的基础设施背景，就想着：好吧，我们自己搞个定制的 grep 索引，肯定快得多，用这个来绕开问题。

And so, a lot of them, I assume because they're using AI and they themselves don't have super deep infra background knowledge, say, okay, we're gonna go build our own custom Grep Index, it's gonna be really fast, and use that as a way around this problem.

大概一年半前，我们在早期开发 Devin 时也遇到过类似问题，那时候还没有 AI，我们就直接问：该怎么处理？

When we ran into this problem about, like, know, maybe a year and a half ago when we were in the early days of building Devin, We obviously didn't have AI, we just asked how to do this.

其实根本不用费劲去建什么新索引，直接用现有的 grep 就行了。

You could just slap off a new Grep index.

你说你手动编写了Devin？

What do you mean you hand coded Devin?

什么？

What?

是的。

Yeah.

你能相信吗？我们真是手写这段代码的。

Can you believe we hand wrote this code?

我们有一些非常出色的运维同事，他们深入排查后说：你知道吗？

And we had our info people who are really amazing, they were looking into it and they're like, Oh, you know what?

我们发现，这个问题的根本原因其实非常简单，但细节很微妙：很多虚拟机底层用的并不是真正的文件系统，而是网络文件系统，数据实际上通过网络缓存在S3里。

We realized that actually the root cause of this problem is actually super simple but fine grained detail, which is that a lot of these virtual machines, actually underlying them don't use real file systems, they use these network file systems where things are actually cached over the network actually in S3.

所以你每次执行grep的时候，其实都在发起网络请求。

So, when you're grepping, you're actually making network calls every time you're doing these things.

这就是为什么在这些机器上grep会慢得离谱。

That's why grep is extremely slow on these machines.

所以，归根结底，我们之前为了把这些机器跑起来，做了多少繁琐的信息整理工作啊。

And so, again, it goes back to, you know, what is all of the crazy info work that we had to do to actually get these machines working.

如果你自己来搞，就会发现这种小细节多得数不清。

If you try to do this yourself, you know, there are tons of small details like this.

最后我们只好把那个网络文件系统给换掉了。

And so we had to eventually go swap out that network file system.

是的，我觉得这事有人写过文章，对吧？

Yeah, I think there's a write up about it, right?

我之前还列过一篇关于虚拟机的，

So I listed one about the virtual Oh,

那完全是另一回事了。

that was a whole other thing.

那是不一样的问题。

That's a different thing.

是那个块差异文件存储格式。

The block diff file storage format.

对，我会把那个资料带过来，那个

Yeah, yeah, I'll bring it Which

这是一种我们自己开发的文件系统格式，让虚拟机能够快速启动和关闭。

is a file system format that we built so that the VMs could be spun up and down very quickly.

简单来说，想象一下你有一个一太字节的磁盘，但你的程序只在这上面写了100行代码。

Basically, the intuition behind this is imagine you have a terabyte of disk and your agent only wrote 100 lines of code on top of that disk.

那保存和启动这个磁盘需要多长时间？

How long does it take to save and bring up that disk?

大多数系统因为没针对这种情况优化，就得把整整一太字节的数据全存一遍、再全读回来，耗时可想而知。

And most systems, because you're not optimizing for this case, it's just like on the order of a terabyte of work because you have to save all of that and bring it back up.

在我们的系统里，我们设计了一种能层层叠加的文件系统。

In our system, we try to build a file system that incrementally builds on top of each other.

每次保存或重启机器时，你只需要处理文件系统实际发生变化的那部分数据。

So, every time you save and bring the machine back up, you're only doing work that is proportional to effectively the diff in the file system.

对。

Yeah.

所以，这大大缩短了Devin的启动时间。

And so, this shaves off a lot of time in the boot up process of Devin.

我觉得这个现在可能已经过时了。

I think this is actually now outdated.

Devin内部现在有了一个更新的系统。

We have a newer system inside of Devin.

不过，确实存在

But, yeah, there's a

很多细微的细节必须做到位

lot of tiny details you have to get right

才能让Devin的日常使用体验真正出色。

here to actually get the day to day experience of Devin could be good.

从技术上讲，这不算智能体，但属于智能体的基础设施。

It's not technically agents, but it is agent infra.

当你把智能体当作产品来卖时，卖的是智能体加上它的基础设施。

And when you sell an agent as a company, you sell agent plus agent infra.

是的。

Yeah.

至少我们现在的做法是这样，好处在于把代理基础设施整合在一起后，我们现在可以自由地把Devin部署到任何我们想要的环境里了。

At least the way we do it and the other the nice thing about having the agent infra being done together is, you know, you we kind of get to deploy Devin in whatever environment we want now.

我们不需要再等底层基础设施提供商去支持VPC、本地部署或者联邦政府云这类服务。

We don't need to wait for some underlying infra provider to also go and support VPC or on prem or Fed GovCloud, for instance.

所以我们现在可以直接问：既然我们掌控了基础设施，那该怎么为你搭建好这套系统？

So we can actually go and out, okay, since we're on the infrastructure, how can we get that set up for you?

对。

Yeah.

而你们则依赖Cloudflare。

Whereas you're a Cloudflare dependent.

Cloudflare负责控制平面。

So Cloudflare runs the control plane.

沙箱环境由Modal提供支持。

The sandbox is modal supported.

有贡献者刚添加了Daytona。

Contributor just added Daytona.

E2B已经在路线图上了。

E2B is on the roadmap.

而且现在有个抽象层，任何贡献者想添加新的提供商，都可以直接加进去。

And I think there's an abstraction in place that if any contributor wants to add a new provider, they can add that in.

是的。

Yeah.

太棒了。

Amazing.

那你接触的客户，一般会去跟其他第三方提供商签合同吗？

Well, what are like how are the customers you work with, do they generally try to then go set up a contract with another one of these third party providers?

还是他们倾向于自己搭建虚拟机？

Do they try to do the VMs in house?

我看到的大多数客户都在用Modal。

Most of them I see using Modal.

我觉得 Modal 的服务很棒。

Think Modal has a Shout great Modal.

我觉得 Modal 的产品非常出色。

Think Modal has a great offering.

它涵盖了你需要的所有沙箱功能，快照就是其中很重要的一部分。

Captures all of the sandbox pieces you need, snapshots being a pretty big piece of that.

而且他们还提供 GPU，整体来看确实是个很不错的方案。

And given that they also offer GPUs, I think it's a pretty nice offering as a whole.

是的。

Yeah.

这点毫无疑问。

No debate there.

Modal 确实很棒。

Modal is great.

尤其是他们的容器服务，用起来最顺手。

Especially, I think the container offering is the most natural.

所以，如果你愿意放弃对完整虚拟机的需求，Modal 是个非常方便的平台，能快速把东西搭起来。

And so especially if you are willing to, you know, forgo the full VM requirements, Modal is a really vast place you can kind of spin something up on.

没错。

Yeah.

Modal 对 Python 的支持是不是有啥限制？

Is there a point so modals vary Python.

我觉得大部分工作负载现在都转向 JavaScript 了。

And I feel like most workload, like, has really shifted to JavaScript.

你们有没有同感？

I don't know if you guys get the same feeling.

嗯，是这样。

Like, so so okay.

我刚开始做 Lanespace、AIE 这些项目的时候，Python 和 JavaScript 还是五五开。

When I started Lanespace and AIE and all these things, was like fifty fifty Python and JS.

对吧？

Right?

大概就是这么个情况。

Like, that's roughly.

我觉得现在不是这样了。

I think that's wrong now.

我觉得JavaScript已经占主导了。

I think JS is one.

我不确定是不是我夸大了，也许像Cognition这样的项目会用C、Java之类的语言。

I don't know if you guys maybe I'm overstating it and maybe for Cognition, there's like C and Java and what have you.

但对于全新的项目，你们有这种感觉吗？

But for new greenfield apps, Do you feel that do you get that sense?

这重要吗？

Does it matter?

我觉得这个领域里大多数库都是优先用Python开发的，尤其是在可观测性方面。

I think that most of the libraries that I see in this space are Python native first, especially in the observability space.

明白了。

Okay.

话虽如此，我觉得整个系统都用同一种语言还是很有吸引力的。

That said, I think that there is a pretty big appeal of having your entire system in one language.

对。

Yeah.

特别是前后端要互相通信的时候，用一套统一的类型定义，确实很方便。

Especially when you have both your front end and back end communicating, you can have one central type Yeah.

这真的很不错。

Which is very nice.

是的。

Yeah.

这正是我不推荐 Modal 的原因。

That's my case against Modal.

或者说，只是因为。

Or it's just Yeah.

你得额外跑一遍，我的意思是，虽然 Modal 也能跑 JavaScript，但毕竟不是运行时原生支持的，多了一道工序。

Then you have to run I mean, you can run JS inside Modal, it's just like one extra step that like isn't native to the runtime.

我不确定是不是。

I don't know if Yeah.

我不知道。

I don't know.

你有数据吗？

You have numbers?

我不知道。

I don't know.

我唯一不喜欢Python的地方就是，只要是AI用Python，总会搞出一些特别奇怪的写法。

The the one thing I don't like about Python is whenever an AI, whenever it's Python, it always does like, the weirdest patterns.

是因为在混用Python 2和3吗？

Oh, because it's, like, mixing two and three or what?

是的。

Yeah.

我觉得就是2和3混用的问题。

Think it's it's something mixing two and three.

是的

Yeah.

比如，我不知道你有没有注意到这个。

Like, the I don't know if you see this.

它总是试图在对象上使用属性。

It always tries to do, like, has attribute on objects.

对，就是这样。

It's like Yeah.

天哪。

Oh, my god.

但话说回来，确实如此。

But it's like Sure.

是的。

Yeah.

你不该这么做的。

You shouldn't be doing that.

它应该报错才对。

Like, it should error

是因为它在训练库代码吗？

if Because it's training on library code?

依我看，这更像是奖励机制被滥用——它就是不想出错。

I think it's more of, like, from what I've seen, it's more of, like, a reward hacking mechanism where it doesn't want to No, never error.

对。

Yeah.

它不希望代码失败。

It doesn't want the code to fail.

所以即使它知道对象有这个属性，还是会去调用 getAtr。

And so it even when it knows it has the attribute, it'll call getAtr on it.

我很多客户转向更自主的代码生成后，我们都把这个设成了代码检查规则。

And for a lot of my clients who have moved towards more kind of autonomous coding, we've put that in as a lint rule.

对。

Yeah.

如果你用了 getAtr，你的拉取请求就会失败。

That if you do getAtr, your pull request is going to fail.

哦，这个话题挺有意思的。

Oh, this is a fun topic.

你能再给我讲讲这类情况吗？

Can you tell me more like this?

比如，还有哪些迹象表明是AI在写代码，需要加防护措施？

Like, what else is AI is a good sign of AI coding that you have to put guards in?

我们刚才在聊OPUS 4.7的事。

So we were talking just before this about OPUS 4.7.

这个新模型特别喜欢写注释。

One of the things this new model likes to do is it writes lots of comments.

不是每行都注，而是在每个函数上面写一大段类似产品需求文档的内容。

Not like it'll comment on every line, but it'll write paragraph PRDs on top of every function.

不过

But

我得说，

I will say,

但不得不说，这些注释已经不像以前那样敷衍了事了。

to its credit, these aren't slop descriptions like they were before.

比如，不再是简单写一句‘这个函数是干嘛的’。

Like, Oh, here's what this function does.

而是会详细说明：为什么选这个方案，有哪些替代方案，以及为什么不选那些替代方案。

It's like, Oh, here's actually the reasoning and why we chose this approach and what the alternatives were and why we shouldn't do those alternatives.

不过信息量还是太大了。

Still too much information.

但我琢磨着，如果想让系统长期能自我维护，这种方向或许是对的。

But I wonder if this actually might be directionally correct if you want systems that can self maintain themselves in the long run.

就像把需求文档也写进代码里，

Like write the specs

把所有上下文都包含在代码里，是的。

in All the context in the code as well, yeah.

所以你是同意的？

So you approve?

但我同时觉得，这确实是个棘手的问题。

I but at the same time, it's this tricky problem.

也许我们可以给用户加个设置，让他们自己决定要多详细。

Like, maybe we'll just give our users a setting or something for how verbose you want it to be.

我其实不太喜欢这个做法。

I haven't loved it.

我觉得评论挺好，拜托，干脆删掉吧。

I like the comment, please, like, get rid of it.

你明白我的意思吧？

You know?

对。

Yeah.

对。

Yeah.

对。

Yeah.

但我能想象，未来可能会出现类似的东西。

But I I could see a world where maybe something of the sort becomes reality.

不知道你们有没有听说过 Git AI。

Don't know if you guys know about Git AI.

知道。

Yes.

对。

Yeah.

我们之前聊过。

We've talked about it.

对。

Yeah.

Git AI 的理念是，如果你运行一个智能代理，那么你发给这个代理的实际指令，应该和代码一起保存在 Git 的元数据里，这样未来的代理就能参考这些指令，代码审查机器人也能用上。

Git AI, the idea behind it if you run an agent, the actual prompts you send to the agent should be stored alongside the code inside the Git metadata so that future agents can reference it, maybe code review bots can reference it.