AI代理的四个层级：千万别做些没用的烂东西吧

好的，大家好。很高兴见到各位。今天真是漫长的一天，你们还坚持来听，这让我很感动。每次我准备分享些什么，看到有人愿意来听，我都深感荣幸。这让我觉得，自己所做的事情是有意义的。那么，今天我想聊的话题是：不要制造垃圾，AI智能体的四个成熟度等级。我想谈的是，很多人向我提到的一个问题，这就像是一种集体性的认知偏差。

所以，基本上就像这样——每个人都觉得周围有一大群机器人，它们轻松自如地处理着各种事情，而你却站在中间，完全不知所措。你困惑极了，不知道该做什么：是应该像拥有15个代理一样，让它们时刻高效运转，自己只管坐享其成？还是该像个苦力一样，逐行阅读每一段代码？要下定决心真的很难。我觉得你来到这种地方，总会被那种正式感压垮，甚至可能引发恐慌发作。

但我觉得，我想……我有点想从这个话题中抽身出来，然后我会说：“各位，我们慢下来吧。先放慢脚步。好好想想我们真正能解决哪些问题，我会切实帮你们构建真正有用的智能体。我想兼顾你们的两端需求——既要快速搭建，又要在某个阶段放慢节奏，把东西投入生产环境。”这基本上就是目标。举个群体性狂热的例子，很多事物其实非常相似。我给你们举三个用户界面的例子吧。

这是三个前沿实验室，我敢保证你们没人能猜出哪个是哪个。呃，其中一个是工厂，一个是Codex，还有一个是Cursor。我肯定你们没人知道哪个是哪个，连我自己都不知道。但没错，这就是重点——所有东西都一样。你想做自己的事。所以，要构建智能体，具体来说，我在这里要展示的是，我想把构建智能体这个问题拆解成四个不同部分。第一部分就是想办法弄清楚这到底有没有意义，到底能不能行得通。这就像你使用一个框架的阶段。

第二部分就像你真正认真的时候，比如“好吧，我真的想在这里做点什么。”现在你开始自己构建东西，比如像状态机一样，构建一个真正的智能体。第三部分是关于用户体验工作流，你使用看板，我认为这是一种很好的形式因素，能够与智能体一起工作。第四部分则是部署到云端。所以，这基本上是我们希望如何与智能体一起工作的大致框架。但我认为它会给你一个很好的启发，告诉你如何解决这个问题。因此，构建智能体的第一级实际上就是直接使用框架。我认为有几个不同的框架，比如LangChain、LangGraph。

我不会用它们。我在客户方工作，需要自己写所有的经验材料。所以，我为什么要用框架呢？因此，我不是给你建议的最佳人选。但我确实认为，如果你在寻找产品市场契合点，遇到像“嘿，我有这个问题，比如想聚合邮件或做一些基础操作，我觉得AI代理可能有用，我可能不在乎最好的模型，只想要能用的东西”这样的问题，任何代理框架都能在半小时内给你一个可用的方案。你只需写代码就行。这是个很好的入门方式。

看到智能体确实能工作，而且你可以自己构建它们，这真是件很棒的事。使用框架会有很多陷阱。我认为最大的问题之一是，如果你真的想把东西投入生产，如果你真的想构建一些严肃的东西，你很快就会意识到，你需要的定制化程度、前瞻性程度、模块化程度，在框架里根本找不到。我知道很多人不同意我的观点，而那些人中的大多数都是错的。总之，第二层就是自己构建智能体，对吧？那么，如何构建呢？我觉得这就像是一个非常复杂的问题，我没办法简单概括。

我来给你讲讲编写智能体代码时的五条规则。这五条规则能帮你大致理清如何构建和编写自己的智能体代码。第一条：始终把每个智能体视为状态机。虽然状态机是大二或大一学的内容，但本质上每个智能体归根结底就是一个递归循环。无论经历多少炒作周期，最终都会回归到递归的while循环——本质上就是带几个条件的while循环。

无论你的代理在做什么，它始终无关紧要——无论是 cursor 时钟还是其他什么，本质上就是一个带有若干条件和若干终止状态的 while 循环。而你需要做到的是，在任何时刻都能在脑海中构建出当前处于哪个状态的模型。比方说，假设你想通过时钟代码来读取几个文件并解释它们。那么流程会从顶部的用户任务开始，比如你要求它“读取几个文件”。接着它会进入“正在读取文件”的状态，并调用读取文件的操作工具，然后它意识到：“哦，我已经读取了文件，这说得通。”

然后它会调用完成工具，并在底部显示“任务完成”，这标志着状态机结束。你可以用非常复杂的方式处理它，比如花8到10分钟甚至几个小时来遍历整个状态机。但本质上，每个智能体都是一个状态机。如果你能将其视为一种思维模型，那么每次构建智能体时，思考起来就会轻松得多。嗯，第二条规则是：你为智能体添加的每一样东西，都有可能让它变得更糟。

我认为这是我们学到的最艰难的一课，也是许多智能体开发者深刻领悟的惨痛教训：对于前沿模型而言，冗长的系统提示、大量边缘案例处理、复杂的条件判断逻辑——所有这些反而会让模型表现更差。我们学到的核心经验就是：给模型让路。前沿模型的能力已经足够强大，你给的指令越少，它们的实际表现反而越好。一个典型例子是Codex代码库中，GPT-5版本的提示词与GPT-5.3版本的提示词相比，后者规模仅为前者的三分之一。

嗯，部分原因在于新模型的能力太强了，如果给它们太多指令和过长的系统提示，反而会导致信息过载——它们被大量指令淹没，反而无法判断该做什么。所以我认为越简单越好，就像每添加一个东西，我都会非常谨慎，祈祷自己别把事情搞砸，并且不断精简。我们甚至为此彻底重写了整个客户端代码，因为发现旧版本里堆积了太多冗余内容。据我所知，客户端代码至少被完全重写了七次。

不过话说回来，团队里的成员可能更清楚。第三条规则是，要让智能体能够轻松融入伪强化学习流程。这确实有点棘手，但说白了就是：无论何时构建智能体，你都需要某种类似命令行界面的工具。原因在于，只要你能通过命令行形式高效构建和测试智能体，就能轻松打造出便于其他编码智能体进行构建和测试的组件。

现在，人类与AI之间正在上演一场互动之舞。过去，人类常引导AI说"这样做"，而我认为此刻已进入AI引导人类的阶段。这正是其中一环——作为人类，若想构建能让AI高效运作的系统，就需要编写恰当的代理文档，运用正确的技能。

构建像CI或CD这样的系统，让其他编码代理能够轻松构建你的代理、测试它、修改它，然后进行端到端测试，这是非常关键的部分。因为这样一来，如果你想做出改动，只需让一个长期运行的代理在并行线程中运行即可。它会完成所有修改、测试，整个流程就能自动运转。但如果构建和测试变得困难，那么利用代理来改进你的代理也会更加困难。这真是超级元啊。第四条规则：别做懒汉。各位，拜托了，看在上帝的份上，千万别做懒汉。我认为，你能获得的吞吐量是如此巨大，能快速处理的事情也如此之多。

我认为，作为真正的工程师，我们学到的最重要的一课是：花时间仔细思考架构、设计以及代理程序应完成的任务大纲，确保其逻辑合理，并且至少花些时间阅读代码——即便不是逐行手写——都是非常值得的。对我们而言，这一点至关重要，因为构建代理的架构设计至少必须由人类完成，而且必须经过深思熟虑。

即使你使用智能体与其对话，也要花大量时间思考架构和状态机该如何设计。不要放任其他模型随意修改代码。而第50条规则是前沿实验室试图限制你的自由度——这是个棘手的问题。很多人会持反对意见，但本质上，当你与前沿实验室的模型合作时，这些模型往往会试图限制你的操作空间，使模型间的可互换性变得更困难。举个具体例子：新推出的模型系列，比如4.6版、1.5版Pro和5.0版，都体现了这种趋势。

他们有一种叫做推理轨迹的东西。推理轨迹是缓存的一部分，也是模型在测试时计算循环中执行的部分。当你与这些模型进行来回对话时，需要以精确的预期格式发送推理轨迹。如果不这样做，响应仍然有效，但性能会下降，而且你无法察觉这一点。很多人其实错过了新模型带来的巨大性能提升，因为他们没有以完全正确的方式使用这些推理轨迹。而且，这些推理轨迹本身也存在不对称性。

所以，有人可能会说，“嘿，也许你可以用Open Router。”但我认为这还不够。我觉得你真的要小心，比如如果你使用不同的Frontier Labs和不同的Frontier Lab API，他们需要你仔细思考API是否运行正常，并且你真的测试过它。嗯，所以，形式因素就像是下一步，比如你如何可视化这些代理，对吧？所以，我认为最初我回到之前的一张幻灯片，我试图向你们展示Codex和Cursor以及其他工具看起来都一样。但我有不同的看法。所以，在3月26日，我发了一条推文，说人们应该使用看板。

看板，我想用过Linear的人应该都熟悉看板。我的观点是，看板就是该用的工具。现场有位叫汉斯的观众很慷慨地分享了他的想法，非常感谢。看板的核心思路是：当你通过智能体工作时，始终受限于推理速度。很多人用Kodak或Alpha这类工具时，每次运行需要8到10分钟。当一个智能体在运行时，你会做什么？你可以刷手机消磨时间，但总不能一直刷下去。所以你会再启动另一个智能体，对吧？这样一来，你至少同时运行两到三个智能体，因为推理速度才是瓶颈。

它们可能都在对同一源头进行变异。因此，你需要隔离它们变异的对象，比如状态隔离和推理边界。在我看来，最佳的用户体验形式是看板，主要是因为它能让你像工程经理一样，可以查看所有智能体。它为你提供一个概览层级的视图，了解它们是什么，同时还能帮助你构建与它们的工作流，比如“如果这两个任务先完成，我就执行另一个任务”。这让你本质上成为工程经理，而你的智能体就是你的独立贡献者，你可以通过看板来观察它们。

我在3月26日提出了这个观点，而10小时前Clock Code也发布了同样的内容。所以我相信自己是对的。嗯，好吧。你可以通过Clock Code客户端使用它，任何你能用客户端的地方都行，选你顺手的就好。那么，你可以把Kanban想象成工程经理的角色，而你就是那个经理。接下来最后一步是：你有了一个智能体，测试过了，也开发完成了，还设计了良好的用户体验界面来与之交互和查看。然后你要做什么？如何让这个智能体既实用又高效，同时能支撑数百万任务和数百万用户的需求？

如果你在一家拥有8000名员工的公司工作，你如何确保所有人都能轻松地与之交互？我认为，与其让人们安装各种东西，在机器上搞那些复杂的工作流程——那些纯粹是垃圾，而且操作起来极其困难——不如干脆全部移除。一次性投入精力，把一切都放到云端。嗯，云代理有很多好处，但最主要的一点是，你可以完全实现并行化，并为每个代理分配独立的机器。

不像云端那样有本地依赖，比如智能体可以设置环境、完成所有用户体验任务。因为目前最缺失的部分之一——很多人没有使用、但我用得相当广泛的——就是云端智能体，因为它们确实能运行很长时间。所以我经常在手机上发送任务，让云端智能体运行15到20分钟。比如说，一个用户体验变更，像是“去构建这个VS Code扩展”。我希望你在这里登录，点击设置，把设置改成选择这个团队，然后在终端里测试这个功能。

而且这些云端代理非常出色，它们会自主完成我刚才描述的问答测试中的所有点击操作，判断测试是否通过。如果未通过，它们会持续迭代、反复尝试。整个过程可能需要50到60分钟。但如果你通过手机或笔记本电脑同时提交大量这类任务，就能拥有一个非常易于定制和扩展的系统。它能帮你快速推进工作。你可以把这些任务交给云端机器运行——就像弥赛亚一样——然后回到电脑前，只需拉取一个PR（合并请求），整个流程就自动运转起来了。

嗯，关于云端代理的另一个方面是，如果你和很多不同的人一起工作，我觉得它就像能帮你建立一个通用的设置，这样很多其他人可以共享，很多人也可以进行修改。嗯，所以我认为引入这个together，会像是最终的形态。所以我的观点是，未来存在这样一种可能：大多数与代理交互的用户体验会是在本地完成，而大多数与代理相关的实际计算则会放在云端。嗯，我认为这四个层次的框架就像是本地处理和云端部署的最后一部分。这些事情是非常困难且复杂的问题。

我觉得如果我是你，我会把这些当作粗略的参考，先这样开始：好，我先做最基础、最简单的事，然后根据我想投入多少精力，再在这些层级之间上下调整。所以，这就是我的想法。嗯，我发表了很多大胆的观点，感觉也留下了不少开放性问题。如果你们有任何疑问或想法，哪怕可能让你感到不适，也欢迎随时联系我，向我提问。嗯，非常感谢你们抽出时间。谢谢你们。我能给你们拍张照吗？好的。可以。好的，谢谢。你们有什么问题吗？

就像我只有一分钟时间。好，这是哦。对。你如何在看板里做规划？呃，我觉得那种来回的需求收集过程，就是让智能体弄清楚它想从我这里得到什么，这反而是最有用的部分。哦，对对对。哦，好，我给你演示一下。我给你演示一下。所以，基本上我认为我对看板的理解就是，如果你看到这个屏幕，你可以进入任何任务，它会显示任务的完整追踪记录。而这一点就像，你现在看到的这个界面基本上就是Codex的实际命令行界面。

我想，我通常的做法就是先在这里聊一聊，然后到某个节点，比如，兄弟，你可以自己继续了，做你的事。到那时候，我就会退出，专注于其他事情。那么，当它需要你审核或者向你提问时，状态会切换吗？>> 是的，是的。所以，一开始就像，比如说，如果我让它读取几个文件之类的，对吧？嗯，一开始它会处于“进行中”的状态，然后当它需要我的参与时，就会进入“审核”状态。嗯，好的。谢谢。