• 请不要在回答技术问题时复制粘贴 AI 生成的内容
echoVic
V2EX  ›  程序员

押注 DeepSeek,再次出发做 Agent

  •  1
     
  •   echoVic · 1 day ago · 2557 views

    前言

    过去一年我做了不少 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 的又一个客户端",我更想做一个能盯着目标自己跑、跑完你还敢信的 Agent 。这部分后面细说。
    • 这是我自己每天要用的工具。哪怕已有不错的选择,亲手做一个完全合自己手的,也值得。

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

    为什么是 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 ,绿加红减直接显示出来——你看着它到底要改哪几行再决定。还能按工具、按文件分别加白名单。三档模式:

    • suggest —— 交互式确认(默认)
    • auto-edit —— 自动批准编辑
    • full-auto —— 全自动

    工具系统:单一事实源

    每个工具由一份 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

    • 单二进制分发:npm 、curl 、GitHub Releases 三条线,装好即用,没有运行时依赖。
    • 启动快、占用低:当作日常命令行工具,冷启动几乎无感。
    • 稳定:定位是一个能长期维护的基础设施,而不是快速试错的玩具。

    支持的平台: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 原生——围绕它的推理和工具调用语义打磨,而不是套一层通用兼容封装
    • 能用——完整的多轮循环、审批、上下文管理、会话历史,不是 demo
    • 便宜——让"把 Agent 当日常工具"在成本上真正成立
    • ——Rust 单二进制,装好即用

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

    相关链接

    24 replies    2026-06-24 21:30:07 +08:00
    jiechen257
        1
    jiechen257  
       1 day ago
    op 不考虑去 DeepSeek 的 harness 组看看机会吗
    waterwawa
        2
    waterwawa  
    PRO
       1 day ago
    挺好的。虽然我自己开发了 Langcli 这个 ai coding agent 。还是开心看到更多方案。
    echoVic
        3
    echoVic  
    OP
       1 day ago
    @waterwawa 欢迎使用、讨论
    echoVic
        4
    echoVic  
    OP
       1 day ago
    @jiechen257 暂时不想动
    Chaiii
        5
    Chaiii  
       19h 7m ago   ❤️ 2
    做 Agent 的现在是不是陷入了开源项目一家亲的情况,你抄我我抄你的无限循环,而且还很适合画饼磨工期,大不了推倒重来
    sentinelK
        6
    sentinelK  
       18h 13m ago
    一直没想明白,Agent 工具目前到底如何区分他们的特点和能力?有没有一个相对量化的指标?

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

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

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

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

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

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

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

    你觉得"没那么多 harness 约束",只是因为 OpenAI 把复杂性藏在了交互界面后面。
    ychost
        19
    ychost  
       12h 12m ago
    @echoVic #18 我都是开 YOLO ,
    ychost
        20
    ychost  
       12h 11m ago
    @echoVic #18 你说的这些加不加都不会影响 Agent 效果。真正影响到效果的极少,相反 claudecode 加加了很多 hooks 干预流程保障效果,但是模型升级之后感觉都可以下掉
    MelodYi
        21
    MelodYi  
       12h 1m ago
    @jiechen257 是的,看 title 还以为他入职了。。。
    wfhtqp
        22
    wfhtqp  
       11h 54m ago
    给开子代理添加一个列表参数,允许主代理将上下文的消息编号扔进去,程序自动处理前缓存,有没有搞头?
    echoVic
        23
    echoVic  
    OP
       6h 41m ago
    @ychost 你是从哪儿判断这些工程上的实现不会影响到 agent 效果的?那如果这样直接跑裸模型不就行了
    echoVic
        24
    echoVic  
    OP
       6h 30m ago
    @wfhtqp 有搞头,不过我可能不会直接做消息编号列表,而是做成 context_refs 。

    主代理只说子代理需要哪段上下文,runtime 自动解析 transcript 、去重、必要时摘要,并尽量把共享前缀稳定下来吃缓存。裸编号在 compact/resume/fork 后容易漂,得用稳定 id 或 range 。

    这个我记一下,挺适合放到子代理上下文隔离这块。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   923 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 62ms · UTC 20:00 · PVG 04:00 · LAX 13:00 · JFK 16:00
    ♥ Do have faith in what you're doing.