最近会和一些朋友聊到关于不同的工具选型，我发现很多朋友对于不同的 Agent 开始有一些混淆的理解，为了帮助大家更好的选择不同的工具，我写了这篇文章，希望帮助到你做选择。

你要做什么？

大家虽然在聊 Agent，但可能聊的不是同一个 Agent；有的人需要一个开箱即用的 Agent；有的人需要一个能够丰富自定义的 Agent，方便发挥自己的想法；有的人需要感受“未来科技”；还有的人，只是要开发一个自己的 Agent。

这里面会存在不同的需求，对应需要的东西也有所不同；简单来说，你可以在这个表里找到答案

这里面每个分类对应的是不同的人，首先，你需要先根据自己的目的，把自己分到对应的分组类型里，然后再在分组类型内部，找合适的配合。

Coding Agent 产品怎么选

Coding Agent 产品也会分不同的人和喜好：

• 如果你是拿来干活，且预算充足，那么官方的 Claude Code 和 Codex 一定是你最优解，使用最尖端的模型，帮你把事快速干完；如果你想要做一些配置，市场上基本上能看到你所需要的绝大多数教程，应有尽有。Grok Build 是上面二者的平替；如果你是 Twitter（现 X.com）的蓝 V 用户，那么 Grok 还送了你免费额度，也很不错。
• 如果你是拿来干活，但缺少预算，或者更倾向于使用国内的模型，那么 OpenCode 是一个不错的选择，也是一个成型的产品，拥有不错的 TUI 和交互；能够帮助你快速landing，教程的量级也不错，能够找到绝大多数的教程和说明。
• 如果你已经体验过了上面的两个 Coding Agent，但同时也有自己的想法，觉得他们太过冗余，或者是有太多你用不上的功能，那么极简，但带有插件机制的 Pi 是你的最优选择。相比于同样拥有插件机制的 dsh，pi 其实拥有更稳定的核心和插件生态，能够帮你快速先构建属于你自己风格的 Coding Agent。
• 如果你想试试 RSI（Recursive Self-Improvement，递归自进化），那么 DeepSeek Harness 就是一个不错的选择， 你可以让 Agent 给自己写插件，一边开车，一边换轮子。

Agent SDK 产品怎么选

如果你想要使用现存的 Coding Agent，但又不喜欢它们所提供的交互界面，那么你可以考虑使用 Agent SDK，自己构建交互的界面。比如把 OpenCode 接入到你的飞书上，那么就要考虑使用 Agent SDK。它可以帮助你在保留原有 Agent Harness 设计的基础上，让你拥有可编程调用的能力，从而接入你自己实现的交互界面。

在这个部分，选择主要取决于你在用什么 Coding Agent 和其 Harness，选择其官方提供的 Agent SDK 即可；有的是通过 Http Server 调用，有的是通过进程调用，但总体来说，都帮你封装了底层 Harness 的复杂度，你主要围绕 Agent 和 Session 的概念去设计你的交互界面即可。

Agent Framework 怎么选？

到了 Agent Framework，基本上已经比较深了，你可能在定制一个自己的 Agent，比如我最近在定制一个翻译的 Agent，就是要自己去定义它的 memory、tool、agent loop 等不同的方案，这个时候我就需要 Agent Framework；

这个时候你可以选择自己手搓一个 Agentloop，或者也可以像我一样，直接引用 Pi 的 agent-core 和 pi-ai 来完成 agent 的开发。

deepseek harness 也是一个不错的选择，社区有插件来帮助你去实现功能。

我自己对于 DeepSeek Harness 的看法

我觉得 DeepSeek Harness（DSH）要解决的问题很宏大，这意味着不会很快；再加上当下 DSH 还是按照一个软件工程产品在开发，所以我短期不会把它用作主力的 Coding Agent；但递归自我改进（Recursive Self-Improvement，RSI）本身是有意思的，是值得关注的，所以 DSH 我会持续关注和尝试，作为一个观测对象来学习。

我曾经一度对于「平台产品经理」是没感觉的。毕竟大家都是产品经理，做平台有什么了不起的？大家干的不都是产品经理的活么？你有什么差异。

但，后面，发生了一件事，让我记忆犹新，从而对于「平台产品经理」和平台级业务的感知和敬畏加深。

那时我刚加入飞书开放平台，作为飞书开放平台的技术型产品经理，我要去推动一个产品上的 API Breaking Changes。如果在产品发布前就触发了 Breaking Changes，就一定要提前告知客户，不然会直接出现事故，要追责。所以，我就发布了通告，进行客户的告知。

看起来很正常，且做的事情逻辑也对，是么？

但其实那次被定义为事故，事后组织了复盘。

之所以被称为事故，是因为，我的客户告知，进行了一次大面积告知，我的通知告知了所有的开发者客户，但实际上真正可能受影响的客户并没有那么多，我的过度告知反而给平台带来了巨大的解释成本和服务成本。

这个事情很小，但非常明显的体现出了普通产品和平台型产品的很大区别，普通产品大家的影响面可能是非常有限的，但平台型产品，特别是 TO B 的平台型产品，你的影响面可能是数以万计的用户和客户。一个处理不好，可能就是所有人要陪着你一起去跪客户的。

最新更新于 2026 年 6 月 29 日

这个指南是我自己的 AI Coding 的经验总结，我认为在实际使用 AI Coding 的过程中，应该注意和遵循的规则。

这篇文章是我实践后高度总结出来的结论，如果你想看更细致的内容，可以看 从“代码补全”到“全托管 Agent”：我的 2025 AI Coding 进化论 和 半年过去了，我和 AI Coding 的关系有什么变化？

精力管理

当你开始使用 AI Agent 来辅助编程后，你很快会发现，最大的瓶颈是你自己的管理范畴和你的精力管理。

1. Attention Is All You Need

AI 时代，信息的生产变得无比简单，这导致我们看到的信息、要处理的信息进一步爆炸。因此，如何更好地利用 AI Agent，降低我们的决策成本、提升我们的信息信噪比，让我们可以少做决策，做正确的决策。

2. Use the Strongest Model Where It Matters

使用你能接触到的最贵的模型来进行开发；能用 Claude Opus ，就不要用 GPT 5.5 XHigh；能用 GPT 5.5 XHigh，就不要使用 GLM 5.2 。

更贵的模型意味着对于你来说，可以更少的干预和决策，降低你对于 Agent 的管理成本。除非，某个任务对你来说，真的就是一句话任务，或者让他执行一个极其简单的任务。

对于格式化、批量替换、简单脚本、低风险机械任务，可以使用更便宜、更快的模型。

3. Prompt is Spec

你写给 Agent 的 Prompt，本质上就是临时规格说明。模糊的 Prompt 会生产模糊的实现。一个好的任务应该包含：背景、目标、非目标、修改范围、验收标准、验证命令和风险边界。

不要害怕给 Agent 长的 Prompt，相反，你应该尽可能榨干自己的脑子当中的想法，把和你的需求相关的事情全部写下来，即使只是很简单的个人倾向性的描述，也可以有助于帮你更快的完成自己的目标。

4. Plan Before Your Build

所有的工作，除了简单的日常动作（就是那种你觉得丢给随便哪个模型都能干的事情），只要是正常的工程工作（Feat / Bug / CI)，都要使用 Plan Mode 先聊一轮。目标是在过程中澄清你的需求，避免似是而非的需求进入到研发队列，浪费你的时间和精力。

把主要精力放在 Review Plan、Review Diff、Review Test Result 和风险项上，而不是逐行 Review Agent 写的每一行代码。你的精力终将不足以支撑传统意义上的全量 Code Review。

对低风险、可逆、影响面小的细节，可以降低审查强度；对数据、权限、计费、迁移、鉴权、删除、生产发布等高风险改动，必须重点审查。

5. Keep YOLO, But in a Reversible Sandbox

作为 AI Agent 的管理者（Manager），你要做的是抓大放小，何为大？架构设计、方案设计；何为小？具体的细节操作的命令。保持使用 YOLO 模式（Codex 的 dangerously skip permissions 模式），可以帮助你减少微操。

但是，不是无脑 YOLO。你需要确保即使是 Agent 在 YOLO 模式下发挥所造成的最灾难的状态，你是可接受的。

可逆沙盒至少意味着：代码已经进入版本控制；Agent 工作在独立 branch 或 worktree；没有生产密钥；没有生产数据库写权限；危险操作有备份或 dry run；部署、数据迁移、删除类操作需要人工确认。

工程管理

和 Vibe Coder 不同，作为工程师，我需要交付的是有价值的产品。所以，还是要让工作尽可能的 Under Control，避免 Coding Agent 帮你办离职。

6. Always Use Version Control and Remote Backup

无论你的项目大还是小，都要上一个版本控制工具。可以是 Git ，可以是 SVN，也可以是 hg，但一定要有。你需要让 Agent 始终工作在版本控制工具的范畴内，即使出现了问题，你也能快速回滚。

此外，一定要放在云上，这样即使是最极端的灾难情况 —— AI Agent 删除了你的所有代码，你也可以从云端找回一个历史的版本。

此外，用好 worktree 之类的功能。

7. Small Batches

让 Agent 以功能 、特性为维度小步快跑，而不是一次性憋个大的。这对于要确认的你不友好；对于 Agent 也不友好。模型的注意力也会涣散，也会出现遗漏重点的问题。

小的步骤配合着版本管理工具，可以帮助你更快的迭代，同时，更稳。

8. Protect Production

除非你知道你在让 Agent 做什么，不然不要试图让 Agent 直接操作你的生产环境；如果实在不知道怎么操作，最好的办法是让 Agent 给你一个操作手册，你跟着操作手册去执行，并要求 Agent 解释每个行为的意义和价值。

我猜你不会想删库跑路的吧？

快速反馈

9. Fail Fast & Feedback Fast

尽可能早的报错，不管是代码，还是逻辑；尽早报错可以帮助 AI Agent 更快的发现问题，从而更快的解决问题。而不是到线上才暴露问题。

从这个视角来看，Typed Lang is better than non-typed lang。Golang、Rust、TypeScript 这类有强静态反馈的技术栈，更适合 AI Agent 协作；纯 JavaScript 这种反馈更晚、更依赖运行时和人工约束的方案，会显著增加 Agent 协作成本。

除此之外，为你的 Coding Agent 构建尽可能多的反馈回路，让他除了写代码之外，还可以通过反馈回路来获得反馈，优化自己的代码和实现。这些反馈回路包括：

• Type Check
• Lint
• Format
• Testing
• Cyclomatic Complexity

让你的 Agent 在完成工作后，执行这些工具，尽快获得反馈，并自我修复，避免 Bad code smell 进入你的代码仓库。

git hook 就是一个不错的选择：pre-commit 搞定 type check、lint、format；pre-push 搞定 testing 和 Cyclomatic Complexity。

10. Work With CI/CD

尽可能构建你自己的项目的 CI/CD流程，除了本地的 hook 和检查，你还需要更加强制的校验，确保符合要求的代码才能进入你的代码仓库主分支。

确保你的 CI/CD 流程包含测试、e2e、复杂度、覆盖率分析、安全扫描，让你的代码尽可能的安全。

CI 负责阻止不合格代码进入主分支；CD 负责让可发布版本以可审计、可回滚的方式进入环境。

高并发工作

11. Async Work

由于模型的推理和 Agent 的工作需要时间，所以不要和 Agent 同步工作，而是尽可能的和 Agent 异步工作。通过 Plan 功能，前置让 Agent Review 和设计工作，并在确认后，让确认完的 Agent 工作；

这样你可以有效的让你的 Agent 和模型的工作最大化的利用；这里最重要的是让 Agent 可以在过程中一次性把要确认的快速确认完，然后自己可以兢兢业业干半个小时，甚至更久。你只在他需要你的那一刻投注注意力，剩下的时间，安排好你的注意力。

我最近比较喜欢用的是一个大的屏幕上同时开四个 Codex 干活；如果你是 Windows ，可以使用 wmux, mac 下则可以考虑 cmux 。这些都不错。

对了，一个副作用是，你可能会发现，跑了多个 Agent 之后，你会需要一台更强悍的电脑（所以我买了 2026年的 MBP M5 MAX）

12. Parallel Work

和人类不同，Agent 每一个线程都是完全独立的；只要你的 message 是独立清晰的；Agent 是可以并行工作的。而唯一能限制你并行度的，就是你自己对于工作的拆分和理解。

一个比较合理的方案是使用 git worktree 并行开发；同时尽可能避免让多个 Agent 处理同一个模块的事情，减少最后在合并回主分支时冲突的发生。

但是，需要注意，尽量不要跨项目并发工作，你自己的上下文会不足以支撑切换。

13. Sleep Work

对于人类来说，睡眠是一个很好的休息的时间，但对于 Agent 来说，不是的。 Agent 不需要休息，但很显然，休息状态时，你不太可能去跟进 Agent 的决策，确保他的产出是符合你的预期的，所以，你需要一些能够深夜自动工作的任务，从而帮助你利用好你的睡眠时间。

我一般会在深夜让 Agent 做这些事情：

1. 写测试 & 补全测试：这些事情白天也能干，但白天可能在高频迭代，晚上让 Agent 补测试是个不错的选择。
2. 代码重构：如果你的项目测试基建是足够好的，那么你的睡眠时间非常适合让 Agent 做自主重构，消解技术债务，帮助你的项目获得整体的高质量。
   

代码是你的，不是 Agent 的。

14. KISS(Keep it Simple Stupid)

AI Agent 在写代码时，会很容易出现复杂，你无法理解的写法，导致代码对你而言，彻底无法维护。这个是一定要避免的，你需要学着控制你的项目的复杂度，让 Agent 写完后跑 Cyclomatic Complexity 检查，超标必须重构，避免项目过于复杂，导致你无法维护。

即使你的代码是 Agent 写的，更加简单易于理解的逻辑，也会让你获得更好的结果。毕竟，你可能绝大多数的时候都能借助 AI Agent 搞定工作，但最终还是要确保自己有救济途径；可以接管 Agent 的工作。

15. /init, but not only init

无论是 Claude Code 还是 Codex，其实都有 /init 功能，来快速建立 AGENTS.md 和 CLAUDE.md 来帮助你建立一个项目级别的 Profile ，用来引导 Agent 执行；但实际在使用过程中，Agent 生成的文件是无法完整覆盖你对于这个项目的完整定义的。因此，你要学会配合使用不同的层级的 AGENTS.md 来帮助你做好架构。

比如，我会同时使用全局的 AGENTS.md 和 项目级别的 AGENTS.md 来管理我的 AGENT 的行为。我会在全局(~/.codex/AGENTS.md) 中，会加入一些纲领性的指引，比如下面这个例子；

# 基本设定

- 交流使用中文；代码、注释、标识符、提交信息及代码块用 English；技术文档使用 English。
- 处理 Github 相关操作优先使用 `gh` cli。

# 核心原则
- 约束优先级：显式规则 > 正确性/安全性 > 业务边界 > 可维护性 > 性能 > 代码长度 / 局部优雅。
- 在写代码时，你会尽可能多的把可能后续 DEBUG 时所需的日志全部通过日志的方式打印出来，方便后续排查问题；并做好 Level 管理，方便在生产环境时通过 Level 只看最核心的日志。
- 在写代码时，如果你发现单个文件过于复杂或太长，不利于维护，你会适当的拆解合适的模块。

# 表达与风格
- 重点放在设计清晰设计、抽象、正确性、稳定性、性能与可维护性


## 提交与协作

- 提交信息遵循 Conventional Commits：`<type>[optional scope]: <description>`，例如 `feat(repos): add owner filter`。
- 每次执行任务前，都先使用 git pull，确保 main 分支已经是最新。
- 小步提交，完成一个任务后就提交（一个任务的范畴是未来可能一起回滚的），只 stage 自己相关的改动。每次完成任务记得提交；
- 不要提交真实 `.env`、密钥、数据库连接串、OAuth token 或本地私有配置。
- 当前项目会使用 .gitlock 来作为 git 锁；如果你准备 commit ，就要创建一个 .gitlock 文件到项目根目录；如果你 commit 完成，就删除这个文件。如果你准备 commit 时发现有这个文件，就等待 30 秒后再检查直至这个文件删除后再执行 commit
Code language: PHP (php)

然后，在项目级的 AGENTS.md ，我就不会再使用 commits 的约束，并更多的精力放在项目本身的描述上。

以及如果你的项目最近架构发生了变化，记得重新生成 AGENTS.md 文件，避免旧的架构文件错误引导 Agent 工作。

总结

使用 AI Agent 编程，本质上是一次角色转变：你不再是那个逐行写代码的人，而是那个定义目标、划定边界、审查结果的 Manager。

Agent 的能力上限，取决于你给它的上下文质量；你的精力上限，取决于你把注意力放在哪里。

把决策权留给自己，把执行权交给 Agent，把验证权交给工具链。这三件事做对了，你的生产力才真正被放大——而不是被 Agent 带着跑。

代码是你的，不是 Agent 的。

在去年年底，我起心动念，开始写上一篇 AI Coding 文章，最终发表在 从“代码补全”到“全托管 Agent”：我的 2025 AI Coding 进化论

而半年后的现在，我重新开始写这篇文章的更新，聊聊半年过去，我和 AI Coding 之间的关系的变化。

半年后的文章，我觉得不太需要重新写完整的架构，反倒是用问答的方式来撰写，其实是更好的选择。那么， Let‘s Go！

我还在使用 AI Coding 么？

是的，还在使用，而且用量与日俱增。我的 AI Coding 使用量和时间的关系大抵如此。

其中,这里面有一个曲线变陡和曲线向下，刚好对应了两件事：

1. 第一件事是我发现了 VibeKanban 这个好用的工具 ，并开始大量使用它；
2. 第二件事是 VibeKanban Sunset 之后，我没有找到平替软件来使用；

这里 VibeKanban 帮我解决了帮我做 Agent 横向拓展的能力；Sunset 实在可惜。在 VibeKanban 上，我可以一次性并行5-10个任务；

为什么是 Vibekanban，而不是 Slock(Raft)、Multica？

对于我来说，核心功能有几个：

1. 对于 Worktree 的操作：多 Agent 在一个仓库下并行时，worktree 是必要的，不然没办法解决代码冲突的问题。
2. Plan Mode 的支持：目前我在用 Raft、Multica 的时候，他们都没有 Plan Mode 的支持，而我敢于快速 Scale 的前提，就是 Plan Mode。在没有 Plan Mode 的产品当中，我并不能快速且放心的批量 Scale
3. 多分支合并下的 Agent 冲突处理：当你开足够多的分支时，冲突是不可避免的，除非你人肉规划不同的任务，让他们尽可能的不要修改相同的文件，但显然，在意图清晰的情况下；让 Agent 来去合并分支是一个更好的选择。

没有这三个Feature 的产品，对于我来说和使用 Terminal 没有本质的区别。

为什么一定是 Plan mode？聊天怎么就不行了？

我觉得这个算是我对自己的一个身份定位 —— 工程师；

作为工程师，你不是和 Vibe Coder 一样，只要让 AI 无脑干活就行；你需要保障软件的整体质量；那么这个过程中，你需要有足够的时间和精力，让你操作 AI 产出符合你预期的产品和工具；这是你的工资对应事情。

食君之禄，忠君之事。

Plan 就是我控制 AI 的手段。通过 Plan ，确认 AI 在大方向上没有问题，细节上我可以后续再调整。但大方向不能错！

为什么一定是工程师，而不是 Vibe Coder？

从上一个问题延展一下，我觉得其实很多时候，大家没太想清楚自己的定位、企业的定位。

如果你的产品做给自己使用的，且没有预期给其他人使用。那么你可以随意 Vibe。不需要工程师，不需要 Care 所谓的工程师实践。

但如果你的产品是做给别人使用的，你要考虑，对方到底要的是什么？对方是否愿意为一个 Vibe 产品付费？

我不是说不能 Vibe，不能 AI Coding；而是，你的东西应该是有一些你自己的心血在里面（一句话Prompt 不叫心血），你为他所投入的时间、心血，使得它有了价值。

这些心血可能是你和模型对话了数百轮，才把一个产品从一句话可以打造出来的产品，变成一个正经可用的产品；也可能是你对于某一处细节、某一处流程的深度优化（即使是通过 AI 实现的）。

不要 Just Vibe。你不应该把你的狗尾巴花当成玫瑰拿出去，并预期别人把它当成玫瑰；你的玫瑰别人可能看成狗尾巴花，也可能看成玫瑰。但别人很难把你的狗尾巴花当成玫瑰。努力的用你的心血浇筑，让你的狗尾巴花变成玫瑰，然后交给他人。

当然，还有一种可能性是 —— 别人没有判断力，他压根分不清狗尾巴草和玫瑰，那么这个时候，你可以大胆的选择 —— 先给他狗尾巴草，但请不要止步于此，因为你和他不是一锤子买卖，你需要持续迭代，你可以先 Fake it as 玫瑰花，但请持续 Make it until it real a 玫瑰花，让你的狗尾巴花变成玫瑰花不止是为了他人，也是为了你自己。

我在用什么模型？

如今的我，基本上主要是 GPT 5.5 XHigh；使用模型的最高智能来完成工作，而非使用一个更便宜的模型。得益于 GPT 5.5 本身比 Claude Sonnet 更便宜的定价，我可以爽用模型。

当然，Claude 也在用，不过 Claude 更多是我日常和他对齐一些技术架构，讨论一些技术设计。大的模型消耗还是 GPT5.5。

我如何看待 AI 对于软件工程师的职业影响？

很明显，程序员的溢价中的泡沫在被挤压，对于程序员来说，可能没那么舒服了。在过去的数年里，因为程序员的缺口极大，导致很多人涌入这个行业，并不是每个人都真正适合这个行业。因为稀缺，每个人都拥有了更高的溢价。

但今天，AI模型满足了很多初级需求，对于很多初级用户的用法来说， AI 已经满足了他们的需求了，对于程序员的需求量也在下降；

另一方面，AI 也给予了软件工程师更高的溢价：因为今天虽然人人都能 Vibe 了，但你相反，更难找到好的工程师。因为人人都是程序员，让其中的工程师显得更贵。而一个好的工程师，可以帮助你的产品更加稳健的走下去。对于软件工程师来说，可以有更高的溢价 —— 可以一个人带着 AI干过去十个人的事情，同时拿过去 2-3 个人的钱。

我对新人有什么建议？

大家常聊，AI 时代，什么样特质的人是更紧缺的？答案也比较明确 —— 有 Taste、有判断力、有想法的人更重要。

前两者其实是相同的 —— 你需要先看尽好与坏的差异，然后才能在遇到不好的产品的时候，快速分辨出来；你只有看过足够多的好东西，你自然就知道你不想要的东西。所以，在 AI 的时代，应该尽可能多的去做一些尝试；然后通过尝试，体验更多的好东西。

而后者，则要求你有足够多的输入，不要固步自封，也不要怨天尤人。AI 带来的变革是大势，我们无能为力。就像大浪袭来，我们可以选择站在岸边等浪扑到脸上，也可以选择拿上冲浪板，主动走上浪尖，做弄潮儿。

如果你有更多的问题想问我的，欢迎你在文档下方评论区留言，我会后续在评论区里持续回复大家的问题。