307 - 硬件工程——AI编程的难点

欢迎收听《Fragmented》，这是一档帮助 vibe 开发者逐步成长为软件工程师的 AI 开发者播客。

Welcome to Fragmented, an AI developer podcast that helps vibe coders become software engineers one episode at a time.

我是你的主持人 Kaushik。

I'm your host, Kaushik.

我是另一位主持人 Iury，我很乐意聊聊如何利用 AI 让你成为一名更好的开发者。

And I'm Iury, the other host of Fragmented, where I'd love to talk about using AI to make you a better developer.

在上一期节目中，我们深入讨论了 agents.md 文件。

In the last episode, we talked a lot about the agents dot MD files specifically.

但从整体来看，这仅仅是拼图中的一小块。

But in the grand scheme of things, that's just one piece of the puzzle.

你提到了一个统称——‘Harness 工程’。

You threw this umbrella term called harness engineering.

至少现在年轻人都是这么叫的。

At least that's what the kids are calling it these days.

我知道你做了大量研究，收集了很多文章，里面有不少值得探讨的内容。

I know you did a lot of research and you have a bunch of articles that you pull from and there's some interesting things to talk about.

但也许我们先给听众们简要介绍一下，今天我们将具体围绕‘ Harness 工程’讨论哪些主题。

But maybe let's start by giving our listeners a sort of overview of what are the topics we're going to talk about specifically around harness engineering today.

在本集中，我们将探讨什么是 Harness 工程，以及它为什么重要。

So in this episode, we're going to cover what's harness engineering and why is this even important.

那么，为什么大家现在都在谈论这个话题呢？

So why are people talking about this at all?

以及如何设计和构建 Harness。

And how to shape the harness and how to build it.

这样听起来怎么样？

Does that sound good?

是的，听起来不错。

Yeah, that sounds good.

我觉得第一个问题非常重要，对吧？

I think the first one is very important, right?

为什么这件事很重要？

Why does this matter?

对吧？

Right?

是的。

Yeah.

为什么要讨论这个？

Why even talk about this?

之前OpenAI发过一篇题为《Harness Engineering》的文章，其实很好地解释了这一点。

So there was this OpenAI post with this very name called Harness Engineering that actually helps explain this really well.

我觉得有趣的是，他们展示的是一个真实产品中的实践。

I think it's also interesting because they're showcasing something that they did with a real product.

这篇文章所引用的是他们用于Codex的代码库。

It's their code base for Codex that they use as reference for this article.

他们拥有超过一百万行代码，并声称这些代码全是自动生成的，共合并了1500个拉取请求。

So they have over 1,000,000 lines of code, and they claim that's zero manually written, like 1,500 PRs merged.

显然，这对他们来说是真正有效的实践。

So apparently, this is the real deal for them.

结果发现，困难的部分其实不是编写代码，而是构建一个能让代理可靠地生成这些代码的环境。

And it turns out that the hard part was not actually creating the code, but it's basically building the environment that makes the agents reliable to build this code.

这是他们有意识的努力，对吧？

It was an intentional effort on their end, right?

他们想的是，如果我们朝着这个方向发展，让代理完全构建整个产品，我们会遇到哪些问题？

Where they're like, if we were to move in this direction where the agent basically builds the entire product, what are the problems we run into?

随着进展，我们该如何缓解并消除这些对代理造成的问题？

And how do we alleviate and remove those problems for the agent as we go along?

这在做事方式上是一个巨大的转变。

It's a very big shift in the way you do things.

对吧？

Right?

你实际上必须尝试不去手动干预它。

You actually have to attempt to not manually touch it.

然后问题就会显现出来，你就得想办法解决它们。

And then the problems start showing up and then you have to kind of figure how to solve them.

这是一个非常有趣的案例研究。

So that's a very interesting case study.

那篇帖子中有一个让我觉得特别有意思的观点，他们明确提到，整个一周他们都会使用代理来生成拉取请求，但随后会花大约20%的时间来清理、校正并把这些修正反馈到系统中。

One point that stood out in that post that I thought was interesting was they said explicitly throughout the week, they would basically use agents to generate the PRs, But then they would spend about a good 20% trying to clean up and make sure that they course correct and then add those corrections into the system.

对。

Right.

这基本上就是催生了这种‘ Harness 工程’的概念，对吧？

And that's basically what gave birth to this harness engineering thing, right?

没错。

Exactly.

工程师的角色正在发生变化，因为我们现在不再那么频繁地编写代码，而是更多地专注于这个引导环节。

It's like the role of the engineer is changing or now that we don't really write the code as much, we're more working on this steering part.

我们是在引导代理，控制它们的走向。

So we're steering the agents where it's moving.

顺便说一句，这简直是个神来之笔。

That's like a mic drop moment, by the way.

随便聊聊。

Just casually.

随便聊聊。

Just casually.

是的，你知道的，人类现在已经不写代码了。

Yeah, you know, humans don't write code anymore.

智能体已经如此先进了。

The agents are so.

不，安拉保佑。

No, InshaAllah.

但没错，大致就是这样。

But yeah, that's pretty much it.

现在的瓶颈不再是能不能写代码，对吧？

The bottleneck now is not if you can write the code, right?

而是你能不能阻止代码偏离轨道或崩溃，你知道的，因为现在有大量代码在不断涌入。

But it's like, can you stop the code from drifting or breaking, you know, because there's a lot more code going in.

天啊，这个话题我们也在未来的节目中聊聊吧。

Man, this is something we should talk about in a future episode too.

我们该怎么去审查所有这些代码呢？

How do we even approach the review of all of that code?

对吧？

Right?

哦，这真是个大问题。

Oh, that's a big one.

生成代码太容易了，但你该怎么真正地审查它呢？

Generating the code is so easy, but how do you actually review it?

普遍的看法是，至少人类应该审查代码，确保不会出错。

There's a general theme where everyone is like, yes, at least the human should review the code and make sure the slot doesn't go in.

但当你面对一千个拉取请求时，根本不可能好好完成审查工作。

But when you have 1,000 PRs coming your way, no chance you're gonna be even doing a good job of reviewing.

到了这个时候，不如想想怎么让智能体更聚焦。

At that point, it's better to think about how can we get agents to focus.

我们如何让代理在代码审查方面做得更好？

How do we make the agents better at reviewing the code?

是的。

Yeah.

这是一个大问题。

That's a big can of worm.

是的。

Yeah.

我们现在来谈谈什么是 Harness 工程。

Let's go now into what is harness engineering.

我不太确定这个想法具体来自哪里，但它的核心是围绕代理塑造环境，使其能够可靠地运作。

So I don't know exactly where I got this from, but it's basically this idea of shaping the environment around the agent so that it can act reliably.

围绕代理塑造环境。

Shaping the environment around the agent.

是的。

Yeah.

如果你仔细想想，他们给了我们这么多工具和调节选项，比如技能、命令、子代理、上下文、围绕代理的所有指令，以及代理可用的工具。

If you think about it, with all the tools and the knobs that they give us, so for example, skills and commands and sub agents and the context and all the instructions around the agent and the tools that the agent have available.

因此，关注点从模型有多智能，转向了它拥有哪些工具、它如何获得反馈，以及人类在何时介入。

So this shifts the focus away from how smart is the model towards what tools does it have and how does it get feedback and when does the human steps in?

这很有趣，因为还有一种不同的观点认为，模型会持续变强，所以你不需要如此关注这些方面。

And this is interesting because there's a different school of thought where, you know, you can think that the models will keep getting better, so you don't need to focus as much.

你知道，模型自己就会知道该怎么做了。

You know, the models will just know how to do it.

这是一种观点。

That's one school of thought.

和AI领域的大多数事情一样，我们不知道今年年底会落在哪里。

As is the case with most things in AI, we don't know where we're going land end of this year.

我们可能会推出某种超级GPT-6，或者不知道的Opus-5，突然间模型变得如此强大，你就再也不用操心这些事情了。

We might come up with some Super GPT-six or, don't know, Opus five and suddenly the models have become so good and you no longer need to bother about these things.

但我们永远无法确定。

But we never know.

至少以今天的状况来看，如果你想获得良好的结果，专注于塑造这个环境是非常有意义的，就像你所说的那样。

At least as it stands today, if you want to get good results, it makes a lot of sense to focus on shaping this environment like you put it.

我想这就是我们在这个播客中试图做的事情。

I think that's what we try to do in this pod.

对吧？

Right?

我们对这些工具和当前状态采取了非常务实的态度，因为没人真正知道我们会走向何方。

We're trying to be very pragmatic about these tools and the current state of because no one actually knows where we're going.

所以，这就是Harness Engineering的整个理念。

So yeah, so this is the whole idea of Harness Engineering.

但我不是母语者，对吧？

But I'm not a native speaker, right?

当我第一次听到‘Harness’这个词时，我有点困惑。

So when I first heard the word Harness, I was kind of confused.

我想我可能是在AI的语境下第一次听到这个词的。

I think I probably first heard it on the context of AI.

所以我当时就想，这玩意儿到底是什么东西？

So I was like, what the hell is a harness?

对于非母语者来说，我找到的一个有趣含义是，它指的是你给马套上的那些皮带，比如当你想控制马的方向时。

For the non native speakers out there, but one of the interesting meanings I found is the one that it's talking about, you know, the straps you put around a horse, for example, when you want to steer it, to control it.

所以模型在这里 basically 就是那匹马。

So the model is the horse here, basically.

你骑着这东西，需要有这些工具围绕着它，才能把它引向正确的方向，让你在正确的地方驾驭它。

You're riding this thing and you need to have the tools around it so you can point it to the right direction so you can ride it in the right place.

对吧？

Right?

松开这个缰绳，你就会从马上摔下来。

Let go of that harness and, you know, you'll fall off that horse, basically.

没错。

Exactly.

哦，这个说法真不错。

Oh, that's a good one.

酷。

Cool.

所以我们一开始简单提过这个，Iury，但现在我觉得有必要把 Harness 工程分成两个部分。

So we mentioned this briefly at the start, Iury, but I think it's important now to split or fork harness engineering into two things.

一个是像我们之前讨论的那样，塑造这个 Harness。

One is shaping the harness like we talked about.

这些是你围绕模型做的、帮助它变得更好的事情。

These are the things that you do around the model to help it get better.

但还有另一种方法，就是直接构建 Harness 本身。

But there's the other approach too, which is building the harness itself.

这更像是如果你想自己打造一个类似 Cloud Code 或 Open Code 的东西。

And this is more like if you wanted to build your own version of Cloud Code or Open Code or whatever.

所以在这集中，我觉得可以把内容分成两部分比较合适。

So in this episode, what I thought it would make sense to do is split the episode into two parts.

第一部分我们先讲如何塑造 Harness，因为这目前看起来最有用、最有效。

The first we're going talk about shaping the harness because that feels like the most useful and effective to do now.

我们会把大部分时间花在这里。

We'll spend a majority of our time there.

但我们也会简要探讨一下构建整个工具链这一概念。

But we'll also touch on this concept of building the harness altogether.

好的，我们来谈谈塑造工具链，这是工具链工程中第一个需要讨论的重要领域。

Okay, let's talk about shaping the harness, which is the first big area to speak here in harness engineering.

在实际操作中，这到底是什么样的呢？

What does that actually look like in practice?

我认为在你的通讯稿中，Iury，我们会在节目说明中附上链接，你提到了五个方面或主题，关于如何塑造工具链。

And I think in your newsletter, Iury, which again we'll add a link to that in the show notes, you pointed towards these five areas or themes, so to speak, around shaping the harness.

我喜欢你对这些内容的结构安排。

And I liked how you structured those.

所以，我们直接进入，逐一讨论这五个方面吧。

So maybe we just jump right in and talk about each of those five areas.

好的。

All right.

是的

Yeah.

我其实读过很多不同来源的内容，它们结构上都不太清晰，但我试着把它们整理成一种有条理的方式。

So I've actually read a bunch of different, like from different sources, and they were not that structured, but I try to organize them in a way.

这并不是任何官方来源，只是我开始思考这个问题的方式。

So this is not any official source or, you know, like this is just the way I started thinking about this.

所以第一个大的主题，我认为是‘代理可理解性’这个概念，这个词可能有点奇怪。

So the first big theme, I think, is this idea of agent legibility, which is maybe a weird word.

我不确定。

I don't know.

不，不，我觉得我明白。

No, no, I think I understand.

但也许你该解释一下‘代理可理解性’，也就是如何让代理更容易理解？

But maybe you should explain that agent legibility, which is like how do you make it easy for the agent to understand?

你能详细说说这个吗？

Can you expound on that?

什么是代理的可理解性？

What is agent legibility?

我认为背后的理念是，如果知识存在于Slack中、某人的头脑里，或者某个链接到其他地方的随机文档中，代理就无法使用它。

I think behind this is the idea that if knowledge lives in Slack or in someone's head or in some random doc that's linked elsewhere, the agent cannot use it.

因此对代理来说，它本质上就不存在。

So for the agent, it essentially doesn't exist.

所以你认为再简单不过的事情，实际上并不在它的上下文范围内，完全无法被发现。

So something that you think it's trivial is just not part of its context and it's not discoverable at all.

就是那些你和产品经理或其他人在Slack里的对话。

It's those things, those conversations you have with your product manager or other people in Slack.

那些不存在于代码库中的Google文档和PRD。

The Google Docs, the PRDs that don't exist in the codebase itself.

你希望把这些内容捕捉并编码到系统中。

Those are the things you want to sort of capture and encode into this.

这似乎就是这里的主题：如果代理无法看到某些信息，就要确保将其编码并纳入，以便它能从你的代码库中读取这些内容。

That feels like the theme here, which is like if there are things that the agent has no visibility into, make sure that you encode and put that so that it can start to read this from your codebase.

否则，它就没有任何知识，对吧？

Because otherwise, it has no knowledge, right?

如果它看不到，就不可能将这些内容纳入它的推理和思考中。

If it can't see it, there's no chance it's going to incorporate that into its reasoning and thinking.

是的。

Yeah.

这意味着代码库必须对代理更易导航，而不仅仅是为了人类。

It's the idea that the repo has to be more navigable by the agents, so not just for humans.

我喜欢这个说法。

I like that.

让代码库对代理更易导航。

Make it more navigable by agents.

但自然的问题是，你该如何做到这一点？

But the natural question is how do you do that?

你建议我怎么做，才能让代码库对代理更易导航？

What are you suggesting that I do to make it more navigable by the agents?

对。

Right.

回到AgentsMD的初衷，现在你不再只是拥有像1000行那样的大量指令，而是可以明确指出：如果你想了解仓库的工作方式，有一个docs文件夹，里面按功能或某种主题组织了相关信息，以及关于仓库运作的跨领域关注点。

So going back to the whole AgentsMD starting point, so now you can have, instead of just having a bunch of instructions like 1,000 lines in AgentsMD, you can actually specify that, hey, if you want to understand how the repo works, there is this docs folder where we organize by feature and or some kind of theme and some cross cutting concerns of how the repo works.

因此，你可以有组件概览、设计规范、编码实践，所有这些内容对代理自身来说都更容易发现。

So you can have some components overview, design rules, coding practices, and all of this becomes more discoverable by the agents themselves.

为了明确一下，你所说的docs文件夹，一方面是要创建这个文件夹并添加所有这些内容，另一方面还要在代理中引用它。

And just to be clear, the docs folder you're saying, one is actually creating the docs folder, adding all of those things, but then also having that referenced in the agents.

像一个地图一样。

Md like a map.

这才是关键所在。

And that's the important piece.

是的。

Yeah.

笔记之间可以相互链接。

And notes can link to other notes.

当代理遍历这些文档时，它能够自行判断这些内容属于哪里以及与什么相关。

When the agent is traversing this documentation, it can figure out by itself like where does this go and what this is related to.

也许我们继续下一个话题。

Maybe we move to the next one.

你接下来提到的主题是什么？

What was the next theme that you brought about?

是的。

Yeah.

我认为很多人也正在意识到并着手解决的一个问题是：关闭反馈循环。

This is something that I think a lot of people have been realizing too, like, and working on is the idea of closing the feedback loops.

闭合反馈循环听起来像是控制理论，或者一些高深的机器学习术语。

And, you know, closed feedback loop sounds like this control flow theory, you know, some fancy machine learning term.

但我们说的‘关闭反馈循环’到底是什么意思？

But what do we mean by closed the feedback loop?

因为很多人经常提到这个词，但实际操作中，你指的是什么？

Because I hear a lot of people say this, but pragmatically, what do you mean by that?

嗯，代理需要知道它什么时候出错了。

Well, the agent needs to know when it messed up.

所以它需要某种形式的反馈。

So it needs some kind it needs some kind of feedback.

所以我认为第一个可能是测试。

So I think the first one could be probably tests.

我认为它们是基础。

I think they're the baseline.

所以如果你让它实现某个功能，它需要有测试，这样当它运行测试且测试失败时，你就不必告诉它出错了。

So if you have you ask it to implement something, it needs to have tests so that when it runs a test and the test fails, you don't need to tell it that it's broken.

它可以自己发现问题。

It can figure it out by itself.

这很有道理。

And this makes sense.

所以这就是即使拥有测试的意义，对吧？

So this is the idea of even having the tests, Right?

因为在上一节关于代理的可解释性中，你还需要告诉代理如何运行测试。

Because in the last section with the agent legibility, you want to also tell the agent how to run the tests.

这部分内容就放在那一节里。

That goes in that section.

在这一节中，我一直在想‘测试框架’这个词，这个词很好。

In this section, I mean, now I keep thinking about the term harness, which is a good term.

你的代码库首先必须具备运行这些测试的能力。

Your code base needs to have the ability to even run these tests in the first place.

是的。

Yeah.

举个例子，可能不太明显的一点是：如果代理要运行测试，那么测试的输出必须足够清晰，以便代理能够据此采取行动。

So for example, one thing that maybe is not immediately obvious is that, okay, if the agent is going to run the test, so the output from the test needs to be clear enough for the agents to act on it.

这可能取决于你正在构建的应用类型或系统类型，但有些测试本身并不直接可操作。

So maybe it's not if you're depending on what kind of app you're building or what kind of system you're building, but some tests are not immediately actionable.

你需要在某个地方检查测试结果。

You need to inspect the results somewhere.

也许会把结果输出到一个代理不知道位置的文件中。

Maybe dumps the results into a file that the agent doesn't know where it is.

所以这些测试实际上对反馈循环没有帮助。

So these tests are not useful actually for the feedback loop.

哦，这是个非常好的观点。

Oh, that's a really good point.

所以不仅仅是编写测试，还要学会如何读取测试的结果。

So it's not just about writing the test, it's also how you read the results from the test.

是的，它需要形成一个完整的闭环，对吧？

Yeah, it needs to close actual loop, right?

所以它需要

So it needs to

我明白了。

I see.

我喜欢你这样做。

I I like how you did that.

所以这就是闭环的那部分，好的。

So that's the closing of the loop part in Okay.

这很有道理。

That makes a lot of sense.

所以写测试本质上就是实现反馈闭环的想法。

So writing tests is basically the idea of closing the feedback loop.

这里还有其他内容吗？

Is there anything else here?

对。

Right.

所以我认为，作为开发者，我们习惯的很多东西其实也是我们需要的，对吧？

So I think most of the things that we are used as developers because we need these things as well, right?

所以如果你曾经试着在记事本里写代码，会非常困难，对吧？

So if you ever try to write code in a notepad, it's really hard, right?

因为你无法确切知道正在发生什么。

Because you don't know exactly what's going on.

这只是一个文本。

It's just text.

嘿，伙计。

Hey, man.

15年前，我们用Notepad++，我不知道，当我学C++课程的时候，我们还得用那个。

15 back, Notepad plus plus I don't know, you know, when I had my C plus plus courses, we had to do that.

我的意思是，别说Notepad++了，我们甚至得在纸上写代码，听起来很疯狂，但确实如此。

I mean, forget Notepad plus plus we had to write code on paper, like, you know, as crazy as that sounds.

难多了。

Way harder.

对。

Right.

没错，确实难多了。

That's exactly it's way harder.

所以这些工具，代理们和我们一样需要它们。

So the the agents the agents need them as much as we do.

哦，我喜欢你这样联系起来。

Oh, I like how you connected that.

好的。

Okay.

好的。

Okay.

这很好。

That's good.

这很好。

That's good.

所以你的意思其实是，还记得那有多难吗？

So you're basically saying, remember how hard that was?

所以别那样做了。

So don't do that.

没错。

Exactly.

尤其是，比如一些基础的东西，像类型检查或者带领团队。

And especially, like, example, even basic things like type checks or lead team.

你能给代理提供的任何反馈都会有帮助。

Any kind of feedback you can give to the agent will help.

所以，静态分析就是二十一世纪的工具，基本上是这样。

So static analysis twenty first century tools, basically.

对。

Right.

然后你会接触到更高级的内容。

And then you get to even more higher level stuff.

不是高级别的，而是一些可能不会立刻显而易见、但你需要构建的东西。

Not high level, but things that maybe doesn't jump to the eye immediately that you need to build.

但比如说，代理需要能够访问日志。

But for example, the agent needs to have access to the logs.

根据你的系统架构，日志可能并不容易获取。

Depending on how your system is built, the logs may be not so trivial to pull from.

所以你需要让代理能够随时获取这些信息。

So you need to get the agent to have that at hand.

我认为即使在OpenAI的帖子中他们也提到过，他们使用的是LogSQL之类的工具。

I think even in the OpenAI post they mentioned, they use LogSQL or something.

我忘了他们具体用的是什么工具。

I forget what the tool is specifically that they use there.

根据第一手经验，我也可以说，在Entropy我们不得不花时间研究如何从我们的系统中提取日志，以便提供给代理，因为其中涉及太多细微的环节。

From first hand experience, I can also say that at Entropy we had to spend some time figuring out how to draw the logs out from our systems in a way that we can feed to agents because there's so many minor points.

例如，你的日志文件可能大得惊人。

For example, your logs could be a ginormous size.

你甚至可能没有API。

You may not even have APIs.

你必须分页调用API，或者设置MCP。

You have to paginate your APIs or you set up MCPs.

但问题是，你所使用的工具并没有现成的MCP。

But then the MCPs don't exist for the tools that you use.

所以所有这些都属于工程工作。

So all of that is this engineering.

对吧？

Right?

你如何才能做到让代理有效地提取这些日志并加以利用？

How do you get to a point where you can get the agent to pull those logs effectively and then use those logs?

因为即使你考虑日志，里面也有时间戳。

Because even if you think about logs, there's timestamp.

我们不想提取一整天的日志。

Don't want to pull the logs for the entire day.

你只想提取在代理需要时的特定时刻的日志，或者使用正确的过滤条件。

You want to pull it for that specific moment where it's useful for the agent to pick it up or the right filters on those logs.

因此，为了确保在代理需要时能正确提取信息，这其中涉及大量所谓的工程工作。

So there's a lot of quote engineering that goes into making sure that you pull the information correctly for these agents when they need them.

你提到的这一点非常好，因为我觉得这正是让‘ Harness 工程’这个概念对我更具吸引力的原因。

This is a very good point that you made, because I think this is what makes this idea of harness engineering more compelling to me.

因为之前我们做的是上下文工程。

Because the previous thing we had was context engineering.

所以上下文工程更像是那种玄乎的东西，你只是输入一些文字，试图从代码库中找到语义之类的东西，试图激发AI的这部分能力。

So context engineering is more in this, you know, like the woo woo kind of thing that you're just typing words and trying to find semantic and whatever from the code base, like try to invoke this good part of the AI.

但这里才是真正意义上的工程工作，对吧？

But here is actual engineering work, right?

好吧，我需要日志。

Okay, I need logs.

我该怎么获取这些日志？

How do I get the logs in?

哦，我需要把它连接起来。

Oh, I need to tie this in.

好吧，也许我可以设置一个钩子，每当模型编写代码时，我就触发代码检查器来格式化我的代码库，确保一切都很严谨。

Okay, maybe I have a hook that whenever the model writes code, then I will trigger the linter to format my code base to make sure that things are very tight.

所以，我认为这属于工程的部分。

So this is, I think, to the engineering part.

很好。

Great.

而且这适用于各个方面。

And it applies across the board.

假设你有截图测试，那么你就需要知道如何阅读截图，甚至首先要设置截图测试。

Say you have screenshot tests, then you need to know how to read screenshots at all or even set up screenshot tests in the first place.

作为移动开发者，你需要能够启动一个模拟器，以便代理可以在模拟器上运行测试并读取结果。

As mobile developers, you need to be able to spin up an emulator or something so that the agent can then actually run the test on an emulator, read the results.

无论你作为人类需要做什么来检查系统，你都需要将系统工程化，以便代理也能做到同样的事情。

Whatever it is that you as a human do to check the system, you need to engineer your system so that the agents can basically do that as well.

接下来是什么？

What's next?

哦，现在这个就变得复杂了。

Oh, that's now there comes a complicated one.

外面有很多不同的观点。

Lots of opinions out there.

但这确实是一个开放性问题。

But and it's that most definitely an open problem.

但我们必须解决内存问题，某种形式的持久化内存。

But we need to solve memory, some kind of persistent memory.

人们对这个问题的处理方式差异很大。

People approach this so differently.

目前关于内存的解决方案非常多。

There's so many solutions out there for memory.

但也许你可以先告诉我们，所谓持久化内存，你具体指的是什么？

But maybe you can start off by telling us, yeah, well, what do you mean by persistent memory?

然后我们可以讨论不同的方法。

And then we can talk about approaches.

是的，如果缺乏一个权威的记录系统、明确的设计决策以及对常见故障模式的理解，那么无论是人类还是代理，都会反复为同样的困惑付出代价，对吧？

Yeah, so here's the idea that if you don't have a system of record or design decisions and some failure patterns, both humans and agents will keep paying for the same confusion over and over, right?

因此，当出现问题时，我们需要能够记住它，以避免再次发生。

So when something goes wrong, we need to be able to remember that so that it doesn't happen again.

我们把记忆看作是防止过去错误的一种方式。

We think of memory as preventing past mistakes.

那么，持久记忆和仅仅把某些东西放在你的代理中，有什么区别呢？

What is the difference then between persistent memory and, say, just putting something in your Agent.

MD文件？

Md file?

因为用记忆基本上可以解决两类问题。

Because there's basically like two things you can solve with memory.

一个是过去决策的概念，另一个是基本上接续你之前停下的地方。

It's like one is this idea of like past decisions, but it's also like basically trying to pick up where you left from.

哦，这非常有趣。

Oh, that's very interesting.

这不仅仅关乎当你从零开始时，想要编码过去的记忆。

It's not just about if you're starting net new, you want to encode past memory.

如果你思考人们是如何处理记忆的，也许你可以再多谈谈这一点，有些解决方案相当随意，比如我认为Claude的做法，就是存在一个记忆。

If you think about how people are approaching memory, and maybe you can talk a little more about this, there's as hacky solutions as I think what Claude is doing, which is there's a memory.

现在是MD文件。

Md file now.

然后你就可以直接使用内存了。

And then you can just use the memory.

MD文件。

Md file.

然后还有一些人使用类似这样的工具？

Then there are people who have tools like what is it?

我认为Shopify的CEO托比有一个叫QMD的工具，它可以将所有内容输入，生成编码后的Markdown，然后保存为嵌入向量，或者我认为它是存入向量数据库的。

I think Toby, the Shopify CEO, has this QMD tool, which is feed it across all and get encoded markdown and then that you save as embeddings or I think it puts it in a vector DB.

我记不清了。

I forget.

还有一些完整的系统，你得设置一套完整的索引流程。

And then there's entire systems where you set up an entire indexing process.

对于那些不记得的人，比如Cursor早期版本，每次你打开Codex时，它都会进行索引。

For those who don't remember, like Cursor in the early days, know, anytime you open your Codex, it would index.

你知道，从简单的markdown到复杂的系统，这中间有一系列不同的选择。

You know, there's a range from like a simple markdown to like sophisticated systems.

是的。

Yeah.

因为本质上，它们是一回事，对吧？

Because essentially it's the same thing, right?

因为所有东西都被标记成了markdown。

Because everything's marked down.

但我认为关键在于你如何使用它，或者如何填充内容。

But I think it's just the way you use it or how you fill that in.

你还记得吗？我们曾经有一段时间特别流行Ragged模型。

You know how we have Ragged at one point, Ragged models were the rage.

我有一个强大的模型，但我想把我的一些经验融入进去。

I have this powerful model, but then I want to layer in some of my learnings.

你可以把那些内容写进markdown文件里，根本没人拦着你。

You can put that in a markdown file like nothing stopped you.

但还有更高效的方法。

But then there are more efficient ways.

模型最终可能会达到同样的结果并给出答案。

The model eventually might get to the same point and give you the results.

但你希望让这个过程更快。

But you want to make that process faster.

所以记忆似乎是一个很好的方式，因为随着这些模型变得越来越强大，智能体最终会得出正确的答案。

So memory feels like a good way to do that because eventually the agent, as these models get really good, the agents will come up with the right answer.

你希望加速这个过程。

You want to hasten that process.

你希望快速且高效地获得这些答案。

You want to get those answers quickly and more efficiently.

你不希望一直消耗令牌。

You don't want to keep burning tokens.

这似乎就是记忆的强大之处。

It feels like that's the powerful piece of memory.

这确实是个非常有趣的话题，因为你开始思考我们是如何记忆事物以及如何提取事实和信息的。

This is honestly a super interesting topic because you start thinking of how we remember things and how we surface facts and things.

你说得对，也许当这些解决方案成熟、人们提出更多想法后，我们应该再专门做一期节目来讨论记忆。

To your point, maybe we should spend another episode just talking about memory once these solutions mature and people come up with more ideas.

我们一定会这么做的。

We'll make sure to do that.

下一个是什么？

What's the next one?

熵控制，对吧？

Entropy control, right?

这可能是我第一次用上我的机械工程背景。

This is maybe the one time I'm using my mechanical engineering background.

我觉得我终于用上点什么了。

I feel like I'm finally using something.

没错。

Exactly.

它表现得相当不错。

It pretty well.

它基本上指的是随机性或无序程度。

It basically means the degree of randomness or disorder.

因此，热力学的其中一条规则或定律指出，熵会随着时间逐渐增加。

So one of the rules or laws of thermodynamics says that entropy over time will gradually increase.

那么，我该如何将这一点与我的代码库联系起来呢？

So how do I connect that to my codebase?

这不正是代码库中发生的情况吗？

That's exactly what happens in a codebase, right?

如果你置之不理，它就会变得一团糟。

If you leave it unattended, it just becomes a mess.

这是个很好的说法

That's a good way

那就是：什么也不做，就别指望它会自然变得有序。

to put it, which is don't do anything and don't expect it to naturally become orderly.

本质上，它会变得混乱。

By nature, it is going to become disorderly.

要保持整洁需要很多努力，对吧？

Needs a lot of effort to keep things tidy, right?

就像你的卧室一样。

Just like your bedroom.

我曾经有个室友，他总说不管怎样，房间都会趋向混乱。

I had a roommate at some point that he used to say that no matter what, the room drifts to chaos.

很好。

Great.

很棒的室友。

Great roommate.

所以我认为，现在由代理生成的代码的问题在于，这种情况被大大放大了，因为代码库中变动的东西多了很多。

So I think the thing with agent generated code now is that this is multiplied a lot because there's a lot more moving things in the code base.

有大量更多的代码被写入。

There's just a lot more code being written.

所以熵失控的可能性大大增加了。

So the chances of Entropy taking over just increase a lot.

这是个很好的观点，因为现在有太多东西在变化了。

That's a good point because there's so much going in.

是的。

Yeah.

对。

Yeah.

所以模式会逐渐偏离。

So the patterns drift.

即使你有完整的Harness工程体系、一堆防护措施，并且非常认真地进行代码审查，它仍然会偏离，文档会过时，辅助函数也可能开始增多。

Even if you have the whole Harness Engineering going on and you have a bunch of guardrails and you're reviewing very diligently, it's still going to drift and docs will go stale and helper functions might start multiplying.

这就跟我们人类的情况有点像，对吧？

So just kind of like we have with humans, right?

因为我觉得现在很多人好像觉得在AI出现之前，代码都是人类写得完美的。

Because I think a lot of people now kind of act like humans wrote perfect code before AI.

这

This

确实如此。

is true.

天啊。

It's like, oh my god.

全是AI写的垃圾代码。

All the AI slob, Code.

你写的也没好到哪儿去。

You wrote it was not any better.

我也见过很多人类写的糟糕代码。

I've seen a lot of atrocities from humans as well.

确实如此。

So true.

确实如此。

So true.

对。

Right.

确实有。

There's yeah.

我们需要设法控制这种偏离。

We we need to try to control this drift.

我认为熵控制本质上就是这个。

And I think the entropy control is basically that.

那么在框架中如何实现呢？

So how do you do that in a harness?

你可以手动解决它。

You can solve it manually.

你可以尝试自动化这些事情。

You can try to automate things.

你可以使用更多AI来尝试控制它。

You can use more AI to try to control it.