没有什么颠覆创新。一个这也比不过、那也比不过的 DeepSeek Coding Agent：Whale。
近期有两位用户吐槽宣传太少（见 issues-272）。那行，我来写一下这段时间一些不太正经的感悟（长时间不写长文了，行文不太清晰，想到那写到那）。
目前 Github 668 stars ，5 位贡献者——感谢他们，也欢迎你成为第 6 位。
这是一位知乎上的用户问的，我也和另一位用了一段时间的用户深入讨论过这个问题。如果说有愿景的话，它大概是这样：做一个 DeepSeek 跑得顺、也"省"💰的 Coding Agent 。从终端开始，将来延伸到桌面。
Whale 诞生于五一假期的一次"一时兴起"。当时 DeepSeek 刚传出融资消息，我猜官方会下场做 harness ，但我并不觉得会对标 CC 。最初是抱着学习的心态，想搞清楚一个 Coding Agent 从 loop 到 tools 到 TUI 的全链路到底怎么运转。结果写着写着发现有人真的在用，就一路维护到了现在。
以下是写 Whale 的过程中的一些感受以及一些慢慢形成的判断。不一定对，或许过 2 个月我的观点就变了。
应该尽量复用现有 coding agent 的 tools, 比如 cc 的， 包括命名、参数等。更简约的可以看看 pi ，它的核心 tools 只有寥寥数个。我想各大模型必然对这业界认可度高的 harness 做过训练的。工具调用的问题可能在少数的 session 里没有体现出来，但随着使用的深入，就会这出一个问题那出一个问题。模型很“聪明”，自然能够另寻它路来完成某个任务，但这不仅浪费 token, 降低用户的信任度，还可能让 agent 走一些极端路径。
这和我们在公司和工作中带着各种各样的约束 agentic workflow 是不同的，这些 workflow 的确定性相对也更高，LLM 本身没有对企业内的工具调用做过训练优化，上下文也往往小的多。而 coding agent 里 prompt 里工具描述的约束力随着 context 变大，模型是很容易开始漂的，就我的使用感受是 DeepSeek 就很喜欢漂到 CC 的工具命名和参数上。Whale 现在这个事情上做得并不好，感觉还没做多久就背上这方面的技术债了。
有了用户的会话数据，无数的成功的、失败的 user cases 就摆在你面前，所有的报错都能得到最大程度的复现和优化。一个有用户数据的 agent, 在工具调用上的顺畅程度上，长期看必然比一个没有的更流畅。或许真的不应该相信那些不保留用户数据的承诺！
大部分的工具调用错误，都是基于我自己使用 Whale 和一些热心用户给的 session 文件做的。让 LLM 去分析这些 session 里是否有可用优化的地方，然后逐个去修复，但这样的用例毕竟是有限的。让不同的 LLM 给不同的用例是一个好途径，大变更我一般都让 CC ，Codex, Whale 给出不用的用户角度的用例，然后让它们拉起 TUI 做回归。但是用户的环境往往要复杂的多，还是很容易出现“在我电脑上是好的”。
做 cost bench 和 cache hit 优化也要尽早的基于真实的数据来做，而不是看 XXX 有这个特性就让 agent 复制过来，LLM 并不是擅长体系的复制很容易搞着搞着就迷失了方向。
之前看完 smolagents 的时候，心想不就一个 agent loop 嘛，区区几百上千行代码 TheShy 来全给弄好了。然而随着功能的增加，渐渐发现所有 agent 都是同一个下场：”屎山”围绕着“屎山”。
仔细看过一些 Codex 和 CC 的代码应该能发现它们的工程质量还是非常不错的，而 OpenClaw 则完全是另一番景象。bug 总是有的，并且因为 LLM 给的回复的不确定性，更加放大了 bug 的数量。这样也就要求在更新速度，维护方式不要固守陈规。
用户的需求自然都是“合理”的，但并不一定适合项目所处的阶段。在 Whale 发布了一周左右的时间点，就有几位用户通过不同的渠道，提出了 Hooks 或者自定义 Plugin 方向的需求。在简单研究了 Codex 和 AGY 的机制后,我又做了一个 oh-my-antigravity 来体验类似的工具是怎么利用 Hooks 和 Plugin 机制的。随后做了一套简单的 hooks 和 plugin 机制，但发现里面需要串联 hook, plugin, mcp, skill, subagent, permission,搞起来并不容易。 最后也没有人在这套机制上做什么扩展，浪费了不少时间，也桎梏了其他的设计。在更早期的时候可以多关注核心功能的优化，不要光满足用户的需求。
当然，过去了一个多月之后，需要重新思考是否需要支持 Hooks 或者自定义 Plugin ，以及支持到什么程度。不是永远不做，而是时机要对。
用 golang 这并不是一个深思熟虑之后的决定，纯粹是一时兴起。有意思的是，G 家的 AntiGravity CLI 同样也是 golang + bubbletea 。在 golang 的技术栈，在 TUI 的选择并不多，包括 CC 和 Codex 在内即使在开最高的 effort 都并不能很好地处理一些限制条件并存的 issue 。 比如渲染、状态、复制、选中等等，crush 等 golang 技术栈项目都在 UI 和体验上做了不小的取舍。
Codex 和 CC 在 TUI 的体验上在我看来是最好的，但 Codex 依然在 Ghosty 存在内容覆盖的问题，因此，在选择语言时应该重点考虑到 TUI 的存在。
有趣的是也是最近 kimi-cli 放弃 Python 彻底转向 TypeScript,完全重写了 kimi-code，AI 的存在可能降低了这样重写的成本，然后用户已经踩过的坑却可能需要再经历一遍。 ，当然非局中人很难窥视到真正的原因。但正如前面所说 harness 本质是一堆围绕着 agent loop 的屎山，快速迭代并不是可选的。，因此语言选择上建议也考虑生态的问题，有参考总比没参考好。
一开始我想把节省 token 作为一个 feature,于是考虑内置一些类似的工具。尝试之后，我建议尽量不要浪费时间在 CodeGraph 、RTK 这类项目上，
我尝试接入 CodeGraph, bench 后发现在自己维护的几个小型项目上 token cost 也并没有什么改善；
尝试 RTK ，bench 后反而发现因为截断工具输出导致 tool calling 次数上升，token cost 也随着上升。
这些项目的宣传都很“美好”，但并不是一定是你所需要的。
上面说的是怎么写 agent 。反过来，天天用各种 agent 干活，也有一些之前模糊、现在越来越清晰的感受。
尽管很多公司或多或少地在 AI 上做 “大跃进”，但在工作中因为有各种各样的约束，新增功能反而谨慎很多。但一个开源项目（特别是一个以个人为主导的）并没有这些类似的约束，就很容易因为 AI 的存在，过度高估引入新功能的容易程度，但这背后是存在代价的。 例子很多，印象较深的是：尝试引入 /rewind 。 开始很美好，颇为得意，但用了一段时间之后发现本地磁盘暴涨，一排查发现是原来的实现对编译产物也做了 snapshot, 后来干脆把这个功能给先去掉了。因此在新功能的引入上还是要尽可能地克制，把核心功能的功能先做好，做顺。
这可以延伸到下面的第二点。
比如让 CC 和 Codex 去读完它们各自的开源代码之后再去实现一个同样的功能，理论上它有了更多的信息，代码就摆在面前，让它去对齐某个 Agent 的实现。这个应该很容易？然而往往它只给搭个架子，勉强能跑。细节却依然需要大量的打磨。这让我进一步意识到 代码是"信息压缩"的产物。那些高质量开源项目的每一行代码都是大量决策、踩坑、重构后压缩成的最小表达。LLM 读到的是这个压缩结果——它不知道哪些细节是必要的、哪些是冗余的、哪些是因为一个特定的 bug 存在的。LLM 能搭框架，但细节密度不够。就像一个熟悉地形的人画地图，他知道哪些弯该转弯，LLM 只能根据地图自己猜弯曲方向。
毫无疑问，CC 和 Codex 不管在产品上，还是模型的 coding 能力上都是最好的！
我个人大部分时间还是在 CC + Codex 上，Whale 大概的 80% 的代码都是 Codex + CC 写的，有难度的 bug 基本都是 CC 修的，20% 的功能和问题使用 DeepSeek 处理的（ Whale ），特别是在 TUI 真实行为测试上，基本都用的 DeepSeek 。 很多改动我会让 Whale 在 Parallel Desktop, 远程 Linux box, 以及本地 Mac 上去做真实的测试。这方面 DeepSeek 可以说是便宜又好用。
DeepSeek 在很多场景下当然足够可用了，但 DeepSeek 和 Claude, Codex 还是有明显的差距！特别是在一些限制条件多的问题上，表现并不好。 这里有一个很有趣的点，当用 Claude 的时候，它并不知道可以使用 tmux 和 prlctl 来做 TUI 测试 ，而 DeepSeek 和 Codex 则知道这一点。
最近又高强度地使用了一下新出的 GLM 5.2 ，感觉国产模型又有了不小的进步。相信应该会有更多的开发者把更多任务交给这些价格更可承受的模型。天下苦 token 价格久矣！希望开源国产模型能不断进步，早日把质量提上去，把价格打下来！
Codex 和 CC 是有 Command-Level Sandboxing 。OpenCode, Pi 等等大量 coding agent 都是没有 sandbox 。平时我也大量在非工作场景里使用 yolo ，但这段时间的开发经历，让我越来越意识到 LLM 有着不达目的不罢休的特性，即使 harness 想尽办法，agent 也依然会失控。
Codex 和 CC 的代码写得很不错,在它们的代码里并没有看到明显的失控的痕迹。 但并不代表那些同样 Github stars 很高的项目，特别是以个人为主导的 Agent 项目在安全和可靠性就值得信赖（这当然也包括 Whale ）。作为使用者还是应该在敏感信息上谨慎一些，做好预算管理等。
这也让我觉得 Kernel-Level Sandboxing 或许有更好的空间，或许是时候做一个 Kernel-Level Sandbox 来给这些 agent 加上一道枷锁了。
个人主导的 harness 可能会有一些特色，Github Stars 或许很高。而新兴 AI 大厂的 harness 团队里它们或许有 10 个或者 50 个 100x 工程师在做优化；它们有大量的用户数据，工具调用可以调得很丝滑；它们还掌控着模型的训练可以让 LLM 在官方的 Agent 里更流畅。因此，从使用者的角度还是应该尽量用官方的 harness, 特别是在生产环境上。
除了总结、记录、分享之外，
一个人维护总是困难的，特别是开源项目，慢慢会失去动力。非常感谢每一位贡献者，以及所有提过 issue 的朋友。
如果你最近正在找机会参与类似的项目，欢迎讨论。方向很多：Desktop 版本、Hooks 和 Plugin 机制的重构、subagent 设计优化、权限体系改进、Command-Level Sandboxing 、多 provider 支持……或者你有其他想法？如果你对其中任何一个方向感兴趣，可以开个 issue 讨论。
再次，走过路过，点个 star ，谢谢各位彦祖！ Whale: https://github.com/usewhale/whale
 |
1 PrinceofInj 几秒前 via Android这个名字跟原来的 deepseek-tui 的新名字 codewhale 太容易混淆了，Google 上搜的时候都经常两个在一起，我一度以为一个是李鬼的项目。 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。