大家好，我是小木头。很不幸我的 Codex 额度又快用完了，不是偶尔一次了，似乎最近越来越容易撞到这个 limit。话说更大的套餐或许能够解决咱们的问题，但实际问题是我现在也囊中羞涩，不可能一直的升级自己的套餐。所以我开始想，有没有一部分开发工作可以不再消耗 Codex 的额度？
所以我在本机打开了 Pi Agent，再把它接到 DeepSeek V4 Flash。接下来发生的事情就很简单了：Codex 暂时不能用，但开发呢不用停。Pi 依然能够完成读、改、测、验这一整套的开发流程，这期我就把这条替代的路线完整地跑一遍分享给大家。
先说明我不是觉得 Codex 不好用，只是在确实限流、limit 这些问题上总得需要找到一个经济实惠的平替开发解决方案。看起来 Pi + DeepSeek 还是一个蛮不错的组合，所以这一期不是去比较究竟谁的跑分更高。
我更想看的是在没有 Codex 额度时，我的这套组合能不能真的把后续的开发工作继续下去。最终我的开发体验非常良好，而且 Pi 给到我的感觉是非常的轻巧高效，整个开发过程也很舒服。
这里最值得讲的倒不是 DeepSeek 之前呢咱们也已经反复介绍过这款模型，而是 Pi 怎么做 Context Engineering。模型负责推理，但它每一步能看到什么、什么时候读取文件、怎么调用工具、失败后怎么继续，都由外面的 harness 来决定。
Composio 最近正好做过一次对比：固定使用同一个 DeepSeek V4 Flash，让 8 种不同的 harness 去完成 30 个可以程序验证的长任务。结果 Pi Agent 完成了 20 个任务，通过率达到66.7%，是这个测试里面报告通过率最高的 harness。
它每次成功任务的估算成本也是最低的，当然这并不是一份简单的绝对公平的总排名，原文也注明了 Pi 使用了不同的 reasoning 设置和两个 provider。但至少说明一件事情：同一个模型换一套 harness，结果真的会不一样，这也是我会尝试选择 Pi 的原因。
在开源圈内也是备受关注的一款工具，DeepSeek V4 Flash 负责推理生成，Pi 负责组织上下文并把事情呢不停的、不断的向前推进直到做完。
Pi 的界面非常克制，打开就是终端，没有一堆需要理解的面板，也不会把执行过程隐藏起来。它读了什么文件、调用了什么工具、准备改哪里，咱们都能够直接看到。需要补约束的时候，咱们随时的提一句就好。
模型呢也只是一个可替换的插件或组件：今天 Codex 没有额度了，咱们就切到 DeepSeek；以后有更合适的模型也不需要换掉整套的工作流。这种轻巧不是说功能少，而是干扰少，我们把注意力留给仓库任务和执行的结果。
这也是我觉得开发体验舒服的原因。当然了，开发体验舒适并不等于开发真正的有效，最后呢还是要看它能不能在真实的仓库里完成任务，能够实现闭环。所以我把 DeepSeek V4 Flash 接进来，用一个完整的任务来跑一跑端到端的流程。
看看究竟使用体验如何？那咱们正式开始，先要确认一下 Node 和 npm 可用，然后安装 Pi coding agent。命令我会放在画面和视频的描述中。
安装后我们先来看看版本吧，确认命令已经进入了 PATH 环境变量，可以在终端直接使用。另一边咱们需要准备一份 DeepSeek API key，我把 key 放进环境变量。
Pi 的配置只需要一个 DEEPSEEK_API_KEY 环境变量，它会自动识别已经配置的这些变量并且加载对应的模型列表。用起来非常的高效，然后咱们用一个简单请求可以确认一下 API 能够正确地返回结果。
现在咱们进入一个项目目录启动 Pi，已经原生支持 DeepSeek。咱们已经配置好 API key、配置好环境变量之后，它加载了 DeepSeek 的模型列表。不需要额外的去做配置文件的编辑，打开模型列表选择 DeepSeek V4 Flash 就可以了。
可以用一个很短的问题确认它不只是在聊天，而是能够真正看到 Pi 暴露的工具。比如你让它读一份文件或编辑一份文件到这里 DeepSeek V4 Flash 已经成为了 Pi 的执行引擎。
我们已经把模型配置好，下面我们不再做玩具式的问答，给它一个真实但边界清楚的开发任务。现在这个项目是 dsh-context：一个给 DeepSeek Harness 做上下文工程的插件，希望将现在开源业界成功的上下文工程经验和设计实现成插件供 DeepSeek Harness 使用。
设计文档已经写的蛮清楚了，这个也是在视频制作前已经整理好的。大致是这么一个流程：期望的是 history 应该从有效的 surface 派生出历史，用 fingerprint 保持缓存的稳定。
并且呢不能让被替换的旧历史重新的进入模型作为演示，咱们就不深入的理解研究这个设计。来看看在 Pi Agent 使用中怎么做的吧？我给它的提示词其实就只有一句话：请先阅读 context-engineering.md 这个文档，再参考源代码 API 的文档等等。
希望先给出 3 步的计划。不要修改文件，它也遵守了这个约束：先读设计文档和现有的实现，再去依赖里面去确认相关的 API。并没有直接修改文件，这步蛮重要的也很关键：文档告诉它应该做什么，但真正接下来该怎么做必须以 harness 当前的 API 为准。
Pi 把这些信息呢都留存在同一个会话的上下文里，它给出了一个三步的计划：把文档里的目标、当前实现和依赖的 API 都对齐。到这一步依然没有修改文件，这个计划看起来蛮合理的。
我也没有追加任何的实现的细节就让它继续：就这么两个动作，先给一句提示词让它阅读和规划，再说一句继续。它就沿着刚才已经建立好的上下文开始后面的开发工作：实现完成以后它会继续运行项目的现有的测试、类型检查，并尝试构建。
整个过程没有再向我提问，我也没有去补充任何更多的细节。它当然也没有要求我来补充任何的实现方面的细节，改动呢集中在了计划设计的文件并没有顺手去重写其他无关的部分。
从阅读到规划到修改，它一直沿着这么一个路径在同一个会话中继续往下执行。我想呢这也是在这段演示当中蛮值得看的部分：接下来是工程检查，现有的测试一次性的通过。
类型检查通过，构建也成功完成，整个过程没有出现报错或者返工。这里要说清楚的是：这些结果说明现有的测试没有回归，类型和构建都成功。但是呢没有为插件的功能做真正的端到端的测试或者在集成环境中做测试，所以我并不会说仅凭这次的运行就宣布所有的功能行为都被证明了。
这个演示的关注点还是开发流程上：在 Pi Agent 的上下文工程的准备组织上面是否顺利、是否流畅？然后我们可以看看 Git diff，改动范围和它刚才的三步计划是否一致。
有没有扩散到其他的无关的模块？那到这里呢，两轮问答完成了这一次的开发工作：再重复一遍第一轮的阅读和规划；第二轮呢我就让它继续，它就完成了修改和工程检查。
接下来看一个蛮重要也蛮有趣的点：就是成本。这张图里高亮的 21 点到 22 点之间就是这波开发所在的时间段，任务的执行呢大约花了10-13分钟这个呢是刚才我粗略统计的。
DeepSeek V4 Flash 的费用是 10 美分，再看 token 吧：缓存命中的输入大概是608万，缓存未命中的输入是47,000多；输出呢是79,000多。只看输入部分，缓存的命中率大概是 99.2%，这已经非常非常的好了。
大量上下文被复用，而不是每轮都按完整的新输入来重新计费。这使得我们的成本非常的低廉，一定程度上也反映出了上下文工程在这个整个任务的执行中发挥了很好的作用。
它也做得很不错，你可以自己评估一下：两轮问答、一次真实的修改、现有的测试、类型检查和构建。10 美分这个开销究竟能不能够接受？当然了这并不是一个严格的 benchmark，但这个结果和 Pi 的设计方向是一致的：控制进入上下文的信息尽量的保持稳定的前缀。
减少不必要的上下文扰动，让提示词缓存呢真正的发挥作用。从刚才数据来看呢，提示词的缓存作用是非常明显的。
所以现在根据我的体验来讲呢：在实际的开发中、应用中呢应该不会二选一，我会把 Codex 和 Pi + DeepSeek 当成两条开发通道。这次最打动我的倒还不是这 10 美分，而是整个平滑的开发过程：Pi Agent 对任务的理解和执行呢做得非常好。
一句话让它读和规划，一句继续就让它完成开发。Pi 没有用一大堆产品功能去帮助模型，它把注意力放在了工具、会话和上下文怎么组织上。开发体验呢是非常直接的。
我的这套组合 Pi + DeepSeek 它的意义倒不是说让我离开 Codex，而是在额度用完之后开发工作能够继续有效地进行。如果你也想试试呢：不要只看模型的单次的问答，从任务的完成过程、总成本、缓存命中以及你需要介入多少次。
看看智能体在任务执行上的效率究竟如何？也不需要把这 10 美分当成所有任务的固定的价格。项目的大小、上下文的长度、模型的定价甚至缓存的状态都会影响到整体的任务执行的成本，这也是你需要去关注和监测的。
但对我来说呢：这套组合已经足够在 Codex 没有额度的时候接过一部分真实的开发工作。毕竟现在看起来 Codex 越来越容易地让我触发这个 limit token，毕竟是一个有限的资源。
在不够用的情况下呢：看起来 Pi Agent 加 DeepSeek也能够帮助我继续的工作。好了我是小木头，大家在使用中有什么反馈也欢迎在评论区给我们留言。那咱们就下期再见吧