使用

这两天有机会体验了下 Devin，感受到一些小小的震撼。

虽然之前已经用过 cursor 和 windsurf，它们用的模型都一样，理论上能完成的任务和智力是差不多的，但用 Devin 感受还是不太一样，有种 AGI 已经实现了的感觉。

Cursor 和 Devin 核心区别是交互范式，Cursor 是 Copilot，在你工作写代码过程中，实时辅助完成编程任务，而 Devin 是一个员工，交给他复杂任务后不用管它，它主动帮你搞定。可能现在这两者完成的很多任务是一致的，但体验有差异。

我试用的其中一个任务，是扔给它开源项目 JSPatch 的 github 地址，告诉它找个 issue 修一下。它会分解任务逐步执行，包括：

1. 访问 github 网站，浏览issue列表，随机看几个 issue 详情
2. 挑了个 block 相关 issue，浏览项目相关文件，寻找与 issue 相关联的代码文件，制定修复计划
3. 写测试用例 → 修改项目代码尝试修复 issue → 跑用例验证(没 iOS 环境没跑起来) → commit 和提交 PR

这个过程是自动和异步的，它跑在虚拟机里，不需要你提供环境，不需要盯着它，它会自己去调研怎么完成这个任务，做完了会来告诉你（如果用 slack，这个体验过程更顺畅，@它下达任务，任务完成slack回复），这跟给一个员工布置任务，等他做完验收结果的体验很一致。

畅想

现在 Devin 解决问题的能力肯定还有限，真正用下来磕磕碰碰很多任务还是完成不好，现在的模型能力下 Cursor 这种 Copilot 的形态是更实用的，但未来理想的形态肯定是 Devin 这种“员工”形态，因为可以解放注意力，无限扩展同一时间能做的事。

可以想象，这种形态未来的优化速度会很乐观：

1. 基础模型的思维规划能力还没收敛，从sonet o1 到 o3 可以看到还在快速提升
2. 即使基础模型能力放缓了，模型在领域上的调优还有很大空间。
3. 更多工具的接入，也能带来更强大的能力和体验。

以及，模型成本必然比摩尔定律更快速的下降，Devin 会持续用最好的模型最贵的方案，但今天 500美金的效果，一年后成本可能只要5美金就能做到。

Devin 所实现的概念早在 23年初 AutoGPT 就提出，只是当时模型能力还不具备，Claude Sonnet / GPT 4o / GPT o1 这种级别推理能力的模型出现后，才具备可用性，Devin 是实现了这个概念下初步可用的雏形，让人看到这个方向已经初步 ready，剩下的就是持续往这个方向优化和扩展了，Devin 确实称得上是数字员工的开端，设计师agent，交易员agent，数据分析师agent，电商agent，预计会陆续出现。

原理

Devin 是怎么实现的？

有个开源项目 OpenHands（前身 OpenDevin），尝试用开源社区的方式去构建类似 Devin 做的事，虽然能力和效果上不能完全对标 Devin，但可以看个基本雏形。相关论文：https://arxiv.org/abs/2407.16741

文中的这张架构图，可以比较好描述 OpenHands 是怎么做：

三个主要部分：

1. Event Stream：记录每一步指令和执行结果，Action 是指令，Observation 是指令对应的工具执行的结果，Action 和 Observation 最终都是以纯文本记录结果。
2. Runtime：程序运行在独立的 docker 容器里，提供一些工具给 Agent 调用执行，当前包括 Python 运行、终端命令行、浏览器
3. Agent：把 Event Stream 里的所有内容作为上下文，输入到 LLM 推理下一步Action。

还有个关键点没有在图上画出来，为什么把 Event Stream 的所有内容输入到 LLM，LLM 就会按照要求推理出下一步 Action？因为输入到 LLM 的除了 Event Stream 的上下文，还有 Agent 本身的 Prompt，这个 Prompt 描述一些处理原则、当前环境、可用的工具、每个工具的参数、预期输出的格式等，以及还配套了一个示例，指引模型按要求输出。这个 Prompt 本身贴在了文末。

我们跟着图上 Event Stream 的示例，跑一下这个流程：

1. 用户输入一个任务命令：“Can you create a list of numbers from 1 to 10, and create a web page to display them at port 5000?” 到 Event Stream
2. 当前 Event Stream 只有这一条命令内容，输入到 Agent，Agent 会拿它跟上述预置 prompt 一起输入给 LLM，LLM 会推理出下一步是调用 Python 去创建 app.py 文件，输出 Action 指令到 Event Stream。
3. 工具 IPython 对应的 Observation 监听到这个指令，在 Runtime 环境执行了这个命令，输出执行结果“app.py created” 记录在 Event Stream 上
4. Event Stream 接收到 Observation 新的执行结果后，Agent 程序会自动继续把整个 Event Stream 记录连同预置 Prompt 输入给 LLM，推测下一步 Action。推测出来的下一步 Action 是把一大段代码用调用 python 命令的方式写入刚才创建的文件
5. IPython Observation 接收到这个 Action，在 Runtime 环境执行命令，输出执行结果到 Event Stream。

接下来就是不断的循环：Action 驱动 Observation 用工具做处理 → 处理结果输出到 Event Stream → Event Stream 拿所有前文内容到 LLM 输出下一步 Action → 驱动Observation 用工具做处理…

后面的6-9步用了命令行工具和浏览器工具，流程是一样的。这个循环流程什么时候结束？有一个特殊的 Action 叫 finish，如果一个任务 LLM 认为完成了，就会输出调用 finish Action，程序接收到就退出循环，等用户下一步输入。

整体就是自动循环让 LLM 预测下一步动作 → Agent 程序调用工具执行动作 的过程。补充一些点：

1. 整个项目不涉及模型训练，纯工程方案，使用通用 LLM 模型，可以配置 Claude/GPT/Deepseek 等，不过可预见的演进是根据用户使用数据去优化模型以达到领域内更好的效果。
2. 这里没有实现像 Devin 在输出 Action 前先会规划好任务的步骤再一步步执行，但要在上述这个系统加上这个规划能力预计不难。
3. 项目使用 BrowserGym 去和浏览器交互，Agent 对浏览器的操作和识别是另一个大课题，有单独的 benchmark 多种方案，待调研。
4. 随着 Event Stream 里链路的不断增加，上下文会越来越长，到一定程度 openhands 会做两种处理，一种是压缩内容，把前面的上下文发给 llm 精练总结，用更简短的内容作为后续的上下文。另一种是让 LLM 对过去的内容进行重要度排序，只选择对预测下一步重要的几个记录作为上下文，具体逻辑在 condenser.py 里。更长的上下文会用向量数据库 ChromeDB 存储。

附：预置prompt

（更多…）