AI代理编码的三种风格
本文探讨了AI代理在编码中的实际应用，作者分享了三种不同的代理编码方法：1) 启动多个命令行界面，2) 以无头模式运行AI CLI，3) 让一个LLM自行创建和管理子代理。作者倾向于第二种方法，并讨论了代理是否需要、多代理协作的挑战以及未来计划。
文章情报
要点
- AI代理被定义为具有LLM能力的软件进程，自主运行以完成任务。
- 作者尝试了三种代理编码方式：多CLI、无头AI CLI、LLM自管理子代理。
- 作者推荐第二种方法，因为它平衡了复杂性和有效性。
- 多代理同时工作会导致文件冲突，建议通过隔离和分支管理解决。
为什么重要
这条新闻值得关注，因为AI代理被定义为具有LLM能力的软件进程，自主运行以完成任务。
技术影响
可能影响模型选型、推理成本、产品能力和评测基准。
一个合理的“AI代理”定义，至少在代理编码的语境下，可以是：一个具备LLM能力的软件进程，在启动时接收指令以完成任务，自主运行（无需人类交互），并具有非确定性行为——代理会根据情况调整，但希望不偏离指令。这些软件进程可以并行启动以加快速度或完成更多任务。
然而，在实践中，“代理”一词常被滥用，可能只是指一个ChatGPT对话，用户提示“你扮演专业税务代理，帮我填写报税表”。Pieter Levels在2025年夏季表达了类似感受：“现在听到人们谈论‘AI代理’通常是个危险信号，我知道他们是非技术人员，只读AI新闻而不实际发货。”
到2026年夏季，情况是否发生了变化？在作者的编码实践中，他探索了几种符合上述定义的代理编码方式，而非挂羊头卖狗肉。以下是三种尝试：
风格1：启动多个命令行界面 作者曾这样做：打开SSH会话到服务器，启动Codex CLI，通过提示要求GPT完成任务。再打开第二个SSH会话，启动Codex CLI，分配另一个任务，以此类推。这种方法简单有效，甚至可以同时使用不同AI提供商的CLI，分散令牌消耗。
风格2：以无头模式运行AI CLI 作者用这种方法为200多个不同网页编写爬虫。基本逻辑是：一个JSON文件包含参数，一个Bash脚本（脚本A）以无头模式启动LLM，脚本A包含带有占位符的提示，用于指导LLM编写特定网站的爬虫。另一个脚本B从JSON中选取20个网站，为每个执行脚本A。作者运行脚本B，检查结果，然后继续处理下一批20个网站，直到完成全部200个。脚本A还要求LLM为每个爬虫编写单元测试，尽管测试并不总是通过，但提高了爬虫的可靠性。这种方法比风格1复杂，但几乎做到了“启动脚本B，一小时内得到200个爬虫”。
风格3：让一个LLM自行创建和管理子代理 风格2依赖Bash和Unix，维护困难。许多解决方案（如Cursor、Codex、Google Antigravity、Claude Code）允许LLM自行启动代理。但作者认为目前还不成熟：距离实际工作更远，错误更难捕捉，中断和恢复不直接，且受限于特定解决方案。因此作者坚持使用风格2（简单情况下用风格1）。
我们真的需要代理吗？ 大多时候不需要。Ethan Mollick通过一个提示和四次跟进创建了完整的实时Web应用，作者的女儿也开发了完整的电商平台，没有使用花哨技术。LLM在搜索信息时也会自行启动代理。作者认为大多数复杂任务都不需要代理，因为LLM本身就能胜任，如果代理有用，LLM会在后台自行管理。
多代理相互干扰的问题 多个代理同时写入代码库会相互干扰。解决方法是让每个代理在不同的git分支上工作，然后合并。但合并可能失败且繁琐。作者在风格2中通过为每个爬虫做充分的准备工作（确保完全隔离）避免了冲突，并在提示中加入硬性限制，禁止代理触碰范围外的文件。
下一步 从几十个爬虫扩展到数百个，并执行它们。目标是熟练掌握这种“自制”多代理设置，以便在其他地方复用。
关于作者 作者是一名学者和独立Web应用开发者，创建了nocode functions工具。