押注 DeepSeek,再次出发做 Agent

6 月 23 日
 echoVic

前言

过去一年我做了不少 Agent:Blade Code(类 Claude Code 的 CLI )、Blade Agent SDK(抽取出来的通用能力集)。它们都跑在 Claude 、GPT 这类海外模型上。

但有件事一直在我脑子里:DeepSeek 这么便宜、这么能打,我自己却没有一个顺手的、围绕它打磨的终端编码工具。

于是有了 Orca —— 一个用 Rust 写的、DeepSeek 原生的终端 Coding Agent 。

GitHub 地址:https://github.com/echoVic/blade-deepseek

npm install -g @blade-ai/orca
export DEEPSEEK_API_KEY=sk-...
orca exec "fix this test"

已经有人在做,但我还是想做

先说句实在话:DeepSeek 的编程 Agent ,并不是没人做。

官方那份 awesome-deepseek-agent 里就列了好几个终端 Coding Agent——DeepSeek-TUI 、Reasonix 、Deep Code 等等,都各有特点。这个方向不是无人区,已经有一批先行者。

知道这些,我依然决定做,原因有三个:

所以这篇文章不打算说"市面上的都不行,只有我的好"。它们都很好,我也在学。我只是想把自己这一版的取舍讲清楚。

为什么是 DeepSeek

我做这个项目的动机其实很简单,就四点:

1. 我相信 DeepSeek 的发展。 从 V2 到 V4 ,它在推理和代码能力上的进步是肉眼可见的。1M 上下文、原生 reasoning ,这些已经足够支撑一个严肃的 Coding Agent 。

2. 它足够便宜。 Agent 是 Token 消耗大户——多轮循环、工具结果回灌、长上下文,跑一个稍微复杂的任务动辄几十万 Token 。在某些海外模型上一天就能烧掉不少钱,而 DeepSeek 的价格让"把 Agent 当日常工具用"这件事真正成立。对个人开发者和中小团队,这点很关键。

3. 围绕它的工具还在早期。 Claude Code 、Codex 、Gemini CLI 都绑死自家模型。DeepSeek 这边虽然有了几个先行者,但生态远没饱和,仍有大量打磨空间——reasoning token 的处理、工具调用的边角行为、上下文压缩策略,都还能针对 DeepSeek 做得更细。

4. 我想帮国模生态做点事,也想跑通一个商业闭环。 模型再强,也需要好用的上层工具把能力释放出来。与其等,不如自己动手。如果能顺手验证一条"国产模型 + 好工具"的可持续路径,那就更好了。

Orca 是什么

Orca 是一个本地终端 Coding Agent ,核心是一个多轮 Agent 循环:

prompt → 模型 → tool_call → 执行 → 回灌结果 → 下一轮(最多 128 轮)

它不是 demo ,是冲着"能当主力工具用"去做的。目前已经实现的能力:

多轮 Agent 循环 + SSE 流式

完整的 prompt → 推理 → 工具调用 → 执行 → 反馈循环,通过 Server-Sent Events 实时输出 DeepSeek 的 reasoning 和 content 增量,你能看到模型"边想边做"的过程。

1M 上下文自动压缩

针对 DeepSeek V4 的百万 Token 上下文做了管理:达到阈值时自动压缩。它不是粗暴截断,而是把对话分成 system / pinned / collapsed / kept 四区,把要折叠的部分交给 DeepSeek 自己去总结,用摘要换回 Token ,重要内容会被 pin 住不动。长任务不会因为上下文爆炸而中断。

分级审批策略 + 内联 diff 预览

读操作永远放行;写文件、执行 shell 这类有副作用的动作,会弹审批框,而且会在执行前给文件拍快照、执行后渲染内联 diff ,绿加红减直接显示出来——你看着它到底要改哪几行再决定。还能按工具、按文件分别加白名单。三档模式:

工具系统:单一事实源

每个工具由一份 ToolSpec 描述,声明它的能力(读文件 / 写文件 / 执行 shell / 联网搜索 / 委派子 Agent 等)。审批策略、给模型的 schema 、对模型的可见性、甚至工具结果怎么解读,全部从这份 spec 推导。一处定义,全链路生效;加工具、改权限不用动十个地方。MCP 工具也走同一套治理,是一等公民,不是外挂插件。

内置工具:read_filelist_filesgrep( ripgrep )、basheditwrite_filegit_statusweb_search,以及 subagentWorkflowupdate_planupdate_goal。也支持用 TOML 描述符在 ~/.orca/tools/ 下注册自定义工具。

子 Agent

同步的子 Agent 循环共享父级的工作区、模型配置和审批策略,跑完把精炼结果交回父级——适合把一个大任务拆给"实习生"去推进。

持久化目标模式( Persistent Goal )

这是 Orca 我自己最看重的一块。TUI 里用 /goal 设一个长期目标,Orca 会在每一轮成功后自动开启下一轮,自己往目标推进,直到完成、被阻塞、暂停或达到上限。目标按 session 持久化到磁盘,进程重启、会话 fork 都不丢。模型干完会主动调用 update_goal 标成 complete 或 blocked ,而不是傻跑。

/goal ship the refactor       # 创建目标并开始
/goal pause                    # 暂停自动续跑
/goal resume                   # 恢复
/goal clear                    # 清除

会话历史

文本模式下自动保存 JSONL 转录,支持 list / show / search / rename / archive / delete ,以及 resume / fork 续接和 zstd 压缩。

orca history list
orca exec --resume latest "continue the refactor"
orca exec --fork latest "try another approach"

工作流 + Hooks

orca workflow run 跑 JavaScript 编写的动态工作流; Hooks 系统支持 session_startpre_tool_usepre_compact 等事件,可以 deny / modify / inject ,把 Orca 嵌进你自己的流程里。

验证门

orca exec --verifier "cargo test" "fix the failing test"

干完活后跑一遍你指定的验证命令,测试过了才算成功。Agent 说"我搞定了"和"测试绿了"是两回事。

为什么用 Rust

支持的平台:macOS ( Apple Silicon / Intel )、Linux ( x64 / ARM64 )。

快速开始

# 安装
npm install -g @blade-ai/orca
# 或
curl -fsSL https://orcaagent.dev/install.sh | sh

# 配置
export DEEPSEEK_API_KEY=sk-...

# 跑任务
orca exec "fix this test"
orca exec --approval-mode full-auto "refactor the auth module"
orca exec --model deepseek-v4-pro "explain this codebase"
orca exec --verifier "cargo test" "fix the failing test"

# 直接进交互式 TUI
orca

模型默认 auto:主循环用 deepseek-v4-pro,辅助任务用 deepseek-v4-flash,在效果和成本之间取平衡。

配置文件放在 ~/.orca/config.toml

model = "auto"
api_key = "sk-..."
base_url = "https://api.deepseek.com"

适用场景

  1. 日常编码:修 bug 、写测试、重构、解释代码库
  2. 成本敏感的高频使用:把 Agent 当作每天都开的工具,而不是偶尔奢侈一下
  3. 长任务:依赖持久化目标模式 + 1M 上下文跑多轮自动推进
  4. 嵌入自有流程:通过 JSONL 事件流、Hooks 、工作流接进 CI 或脚本

关于未来:不止 coding

Coding 是我选的第一个切口,但不是终点。

你能看到,Codex 、Claude 这些团队都在把 Agent 从"写代码"往更广的"完成工作"延伸——读写文档、跑流程、调工具、查资料、把一连串琐碎任务自动接起来。代码只是 Agent 能力最容易被验证、也最早跑通的那块。

我的布局也是这样:先用 coding 把内核打磨扎实——多轮循环、工具治理、上下文管理、持久化目标、可信交付——这些能力本来就不是编程专属的。一个能盯着目标自己跑、改东西前给你看 diff 、跑完帮你验证的 Agent ,换个工具集和场景,同样能去做办公和更一般的"work"。

所以 Orca 现在的架构是按"通用 Agent 内核 + 可替换工具层"来设计的:ToolSpec 驱动的工具系统、能力分级审批、MCP 一等公民、Hooks 接入外部流程——这些都不绑定编程。今天它帮你写代码,往后它会帮你处理更多本该自动化的工作。

这部分还在路上,但方向我想先讲清楚:Orca 的目标,是一个围绕 DeepSeek 的通用工作 Agent ,coding 是它的起点。

总结

DeepSeek 的编程 Agent 已经有人在做,做得也不错。但这个生态还早,我也有自己想走的路:比起"又一个能接 DeepSeek 的客户端",我更想做一个能盯着目标自己跑、跑完你还敢信的 Agent——长程自主、能力治理、可信交付,这是 Orca 真正下注的方向。

基本盘它也都有:

如果你也在用 DeepSeek 写代码,欢迎试试 Orca ,也欢迎 Star 、Issue 和 PR 。这条路,我想和更多人一起走。

相关链接

4515 次点击
所在节点    程序员
32 条回复
jiechen257
6 月 23 日
op 不考虑去 DeepSeek 的 harness 组看看机会吗
waterwawa
6 月 23 日
挺好的。虽然我自己开发了 Langcli 这个 ai coding agent 。还是开心看到更多方案。
echoVic
6 月 23 日
@waterwawa 欢迎使用、讨论
echoVic
6 月 23 日
@jiechen257 暂时不想动
Chaiii
6 月 24 日
做 Agent 的现在是不是陷入了开源项目一家亲的情况,你抄我我抄你的无限循环,而且还很适合画饼磨工期,大不了推倒重来
sentinelK
6 月 24 日
一直没想明白,Agent 工具目前到底如何区分他们的特点和能力?有没有一个相对量化的指标?

如果没有的话,那这些 feature 的意义到底在哪里……反复迭代 Agent 工具的最终目的又是什么……
visper
6 月 24 日
用的 reasonix 的 1.x 版本,听说 2.x 版本 bug 多没换。用起来感觉我没收不错,能处理问题,看着缓存效率高感觉便宜,心理上感觉不错。唯一不好的就是,cli 的 ui 界面相对 opencode 都差太多,思考处理过期基本看不出来它在干什么,只有看最后结果。不知道现在这些效果怎样。按想象来说,agent 编排和 prompt 这些也会对模型能力有影响。不知道好用不所以有时候不会随便换用。
lete
6 月 24 日
闲的蛋疼找事干
ychost
6 月 24 日
AI 写的 Agent 给 AI 用。 本质还是大模型能力强才行,Harness 这一层能做的东西很少,大模型一个版本迭代前面做的各种工程兜底反而是一种负担
zj
6 月 24 日
后续有支持 Windows 计划吗?
echoVic
6 月 24 日
@sentinelK 现在没有统一的量化指标,大家都只看结果,结果是通过完整链路体现的,比如任务完成率、能自主推进多少轮、工具调用是否稳定、上下文管理、权限/可观测性、验证命令通过率、陈本和耗时。

这些 feature 不是为了堆功能,而是在提高“可交付任务”的成功率。coding 是最好的切口,因为结果可验证:代码能不能跑、测试过没过、diff 改了什么都很清楚。再往后我觉得会从 coding 走向 work ,各家抢这个领域,本质上也是在抢真实任务闭环和数据飞轮。

插一句,好不好用其实也主观,cc 和 codex 不也是口碑不断交替
echoVic
6 月 24 日
@visper reasonix 我也关注过,它确实是 deepseek 里做得比较早、也比较有代表性的一个,,尤其是高缓存命中这块做得很有意思,我还参考了它的方案优化了 orca 的缓存: https://mp.weixin.qq.com/s/1CDceJGRU5TdUwhKkj33cA?scene=1

交互确实很关键,agent 如果只给最后结果,中间过程完全不可见,用户很难建立信任。所以做 Orca 之前我就在想,应该尽量把 reasoning 、工具调用、diff 、验证这些完整过程展示出来,后面也会继续参考一些优秀产品的交互。

同一个 deepseek ,外层 harness 做得不一样,最后稳定性、缓存命中、可控性都会差很多。所以我也不觉得谁一定替代谁,更多是不同取舍。你如果后面试 Orca ,欢迎直接提 issue ,谢谢。
echoVic
6 月 24 日
@ychost 模型负责能力上限,harness 负责把能力变成稳定交付。

如果只是很薄的一层 prompt/skill 包装,那确实价值有限。但我理解做在 agent 里的 harness 不只是 prompt ,还有上下文管理、工具治理、权限、可观测性、失败恢复、验证收尾和成本控制。模型越强,上限越高; harness 做得越扎实,能力越能稳定落到真实任务里。
echoVic
6 月 24 日
@zj 有这个计划,还有 app 版
zj
6 月 24 日
@echoVic #14 期待,现在在用过 Reasonix ,希望在 token 成本控制上也加把力。
placeholder
6 月 24 日
名字不知道怎么读,算了不用了。
ychost
6 月 24 日
@echoVic #13 名词很多,真正落地的还是之前那一套。codex 实现就很简单,没那么多 harness 约束,效果依然很好
echoVic
6 月 24 日
@ychost 恰恰相反,Codex 的 harness 一点都不简单。它有沙箱隔离、网络策略、文件系统快照回滚、超时空之、多步验证循环。

举个例子,/goal 这个命令背后就是一整套 harness 的落地——它不是简单地把你的需求丢给模型,而是由 harness 负责拆解任务、管理多步执行状态、在每一步做验证和回滚决策。

你觉得"没那么多 harness 约束",只是因为 OpenAI 把复杂性藏在了交互界面后面。
ychost
6 月 24 日
@echoVic #18 我都是开 YOLO ,
ychost
6 月 24 日
@echoVic #18 你说的这些加不加都不会影响 Agent 效果。真正影响到效果的极少,相反 claudecode 加加了很多 hooks 干预流程保障效果,但是模型升级之后感觉都可以下掉

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1222331

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX