Chatto 是机器人：我的 100% 智能体开发工作流复盘

[ 我最近开源Chatto，这是我过去大约9个月一直在开发的一款可自托管的团队与群聊应用。我觉得它真的太棒了！所有试用过它的人都一致认为这一点！（对此我由衷感激！Chatto 受到的积极反馈让我倍感谦卑。）

但更令人惊喜的是：我在构建和维护 Chatto 时所采用的工作流程几乎完全以“代理”为导向； 事实上，自今年2月以来，我竟然连一行代码都没写过。 然而，我从未像现在这样全身心投入于一个代码库之中。 通过“代理式工程”，我得以将更多的时间花在对代码进行理性思考上，而不是一味地敲击键盘编写代码。 而最终的结果，正是我感到自己迄今为止打造的最出色的应用程序。

在这篇博客文章中，我想为大家全面梳理一下我的工作流程。 如果你对借助人工智能来构建软件这一想法本身抱有强烈的抵触情绪，那么我恳请您务必继续阅读； 你对“与编码代理协作”的理解或许还很不完整，而这篇文章或许能帮助我们更细致、 更全面地看待这一领域。

（哦，顺便一提：这篇博客的全部内容确实是我亲笔撰写。让AI来写博客文章，简直太蠢了！千万别这么做！）

让我们开始深入探讨吧。我的工作流程主要由三大支柱构成：工具、代理指导以及代码评审。接下来，我会逐一为大家介绍这些环节。

工具

模型与代理

自去年12月起，我便一直订阅了一家顶尖前沿实验室的服务，每月只需支付200欧元。 直到两个月前，我还在使用 Anthropic 的 Claude Code；后来我对他们失去了兴趣，转而选择了 OpenAI 和 Codex。Claude 现在变得异常不可靠，而且 Anthropic 对其用户能够如何使用订阅服务有着一些相当令人不快的看法。 OpenAI 的模型则非常出色，它们能更快地切入主题，而且相比 Anthropic 的模型，也少了许多让人觉得烦人的“唠叨”； Codex 的 CLI 比 Claude 要好得多，也更符合计算机的本性；更值得一提的是，OpenAI 还慷慨地为用户提供了大量速率限制重置的机会。

我并不喜欢每个月向一家位于美国的前沿实验室支付200欧元的费用。 这可是一大笔钱——我经常把这笔钱比作“每个月买一台 PS5”，尽管这个说法已经不再准确了——而如此依赖一家供应商，尤其是还要依赖一家总部位于美国的供应商， 实在不太理想。不过，我认为这些只是暂时的“小插曲”，归根结底，这份订阅所带来的价值远远超出了这些小小的不便。 它让我能够以极快的速度推进工作，几乎将构建复杂应用过程中大部分的繁琐琐事都彻底抛诸脑后。 如果没有这份订阅，Chatto 也许会存在，但它的效果恐怕远不如现在这般出色。

说实话，这真的是我这辈子花在每月200欧元上的最划算的一次投资。

不过，和许多其他人一样，我也期待着，未来本地模型终将接管这项工作的“底层80%”。 我对这个领域的种种进展充满期待，并且深信，五年之后，当我们回望2026年时， 一定会因为当初为了只为了让一台超级计算机为我们代劳写几行 Go 代码而付出这么多钱而哈哈大笑。（除非那台超级计算机先把我们给“干掉”，而据我判断， 这种可能性如今已经高达50%。来吧，机器人！ ）

多代理协调器

编码代理有时会花上很长的时间。如果你只是单纯地运行一个会话，往往会导致大量时间浪费。

解决这个问题的办法就是并行化：只需让多个代理同时并行执行不同的任务。 由于无法在同一目录下完成这些任务，因此你需要借助 Git 工作树，为每个代理分配独立的小型工作空间。 在每个工作树中，你应当运行项目的初始化任务，并复制一份你的编码代理。 这一切加起来，既省去了大量重复劳动，又避免了手动管理 Git 工作树和运行脚本的繁琐过程。因此，你不妨选择一款代理编排工具，让它替你完成这些繁琐的工作。

而市面上这样的工具其实多得数不胜数。 我过去半年左右一直在使用的，正是……导体， 是为数不多的闭源选项之一。我并不特别喜欢它的这一方面，但除此之外，整体来说还算不错。 过去它也曾出现过一些相当糟糕的性能问题； 我之所以至今仍在使用它，主要是因为我已经习惯了它，而切换到其他工具会带来不少麻烦， 而我并不想费心去应对。

不过，等我最终彻底放弃它时，我新选择的工具很可能会是…… 散步它沿用了与Conductor相同的用户界面模式——它们都是这样——但它是开源的， 且架构更加合理：服务器进程负责运行实际的代理，而用户界面仅作为客户端与之连接。 这正是我原本设想的这类工具的工作方式。如果我自己的建造了， 我对此深表感激。

在 Conductor 中，开始一项新任务只需轻按一次 Cmd-N 键；我输入任务信息后，Conductor 会自动搭建工作树、初始化项目并立即投入工作。 当代理完成任务后，我会收到一条通知； 随后，我可以查看其编写的代码，或者点击“运行”按钮，启动项目的本地副本（这一功能可灵活配置， Conductor 还能为每个工作树分配端口范围，从而让你在不产生冲突的情况下运行多个应用实例）。 另一个按钮则会在我的浏览器中打开该项目，供我进行测试。

如果有什么需要与代理讨论的事项，我只需继续对话； PR 视图甚至允许我在单个差异行上留下评论，就像一种微型 GitHub 一样。还有一个醒目的“审阅”按钮，可以启动第二个代理会话，并附带相关说明， 指导我对这些更改进行审核；如果你愿意，Conductor 还能为你配置不同的代理和模型来应对此类场景。

一旦我对结果满意，只需轻按一个按钮，即可将成果以 PR 的形式提交；当持续集成通过时，Conductor 会及时通知我；随后，又一个按钮让我能够将该工作合并到我的主分支中。 若持续集成失败，“合并”按钮则会显示“修复错误”； 只需轻点该按钮，代理便会自动检查 CI 输出（Conductor 会将其附加到提示信息中），并处理各项失败问题。

这就是它的实际呈现方式：

以上就是整体的工作流程：启动新任务、审阅代码、提交 PR、处理持续集成、合并代码——完全如同你所习惯的那样！只不过现在，你可以同时并行执行多项操作。

或许你会想：既然这一切都只是通过点击下一个按钮来推动进程，那为什么不彻底实现自动化呢？ 我理解这种想法——但我认为，真正让 Conductor 及其同类工具如此强大的，恰恰在于用户依然在不断做出决策。 我并不认为全面自动化是目标，也不应成为目标； 相反，我建议大家务必谨慎对待那些声称“自动化是目标”的人。

代理指南

关于编码代理以及 LLM 本身，有一件至关重要的事情必须牢记——而事实上，有相当多的人却往往忽略了这一点——那就是： 它们绝不是只掌握你问题答案的小型“先知”，也并非能凭空变出你所请求的一切。

不妨把 LLM 和代理想象成天然语言自动化连接器。我坚信，一旦你真正领会了这一点，你就会比绝大多数人更擅长使用 AI。

代理技能

你进行自动化操作的主要工具是… 代理技能它们是你的秘密超能力， 作为载体，用于规范你的工作流程、偏好、风格指南等。

自定义技能能够将一个原本只能统计“strawberry”中“r”的数量的模型， 转变为一款真正了解你项目方方面面的机器。 我认为，编写并维护良好的技能，对你的代理式工程成功贡献高达90%，而且远比单纯下载一堆随机的第三方技能要重要得多（我强烈建议不要这样做， 原因不止一个。）

接下来，我将介绍自己的一些技能…… 查托仓库.

术语表与建筑清单

首先，对于任何非简单的项目，你都必须建立一套语言体系。 该…术语表 技能负责处理此事，创建并维护一个… 项目中使用的术语及其所指代的内容清单. 你会轻松得多……