PTC 模式深挖DeepSeek Harness 凭什么说自己「省 Token」DeepSeek Harness 的四种模式里PTCProgrammatic Tool Calling程序化工具调用是最有特色、也最反直觉的一个。传统 Agent 是「模型出调用 → 执行 → 回填 → 再出调用」的一轮轮慢速循环PTC 让模型直接生成一段代码把多轮工具调用组合成一次执行。这一篇从头讲清楚PTC 到底是什么、它跟传统 Agentic Loop 的差异、以及它凭什么能省 Token、省时间。一、先看传统 Agent 的「笨办法」传统的工具调用循环Agentic Loop长这样第 1 轮 模型: 我需要看下文件列表 → 调用 list_files (3k 上下文) 第 2 轮 工具: 返回结果 → 回填给模型 第 3 轮 模型: 我需要读取 main.py → 调用 read_file (6k 上下文) 第 4 轮 工具: 返回内容 → 回填 第 5 轮 模型: 我需要定位 bug → 调用 grep (9k 上下文) 第 6 轮 工具: 返回结果 → 回填 第 7 轮 模型: 我需要看测试 → 调用 read_test (12k 上下文) ...持续下去每一个「模型轮次」都要把当前全部的对话上下文重新发送给模型一次。上下文只会越滚越大第 1 轮发送 3k第 3 轮发送 6k第 5 轮发送 9k第 7 轮发送 12k……这就是为什么 Agent 任务的 Token 消耗会「指数级」膨胀——不是模型的输出贵是每轮重发的历史上下文贵。二、PTC 的思路让模型「写代码」而不是「一轮轮喊话」PTC 的原始想法非常直接既然模型知道要干什么为什么不让它把「接下来要干的活」写成一段代码一次性执行在 PTC 模式下模型不再逐轮调用工具而是生成一段程序化调用脚本# 模型生成的伪代码示意 files call_tool(list_files, {path: .}) main call_tool(read_file, {path: main.py}) matches call_tool(grep, {pattern: bug, path: src/}) tests call_tool(read_file, {path: test_main.py}) # 基于以上结果做判断输出最终结论 conclusion analyze(files, main, matches, tests)Harness 的内核拿到这段代码后顺序执行里面的工具调用把多次调用的结果一次性收集回填给模型。整个过程只有第 1 轮 模型: 生成一段程序化调用代码3k 第 2 轮 内核: 顺序执行代码中所有工具调用0 模型 Token 第 3 轮 模型: 根据完整结果做最终输出3k对比一下传统方式的 7 轮3k6k9k12k... 递增PTC 只要 2 次模型往返。省掉的不是某一次调用的成本而是每次重发累积上下文的成本。三、PTC 与传统 Loop 的本质差异维度传统 Agentic LoopPTC 程序化调用模型往返次数每次工具调用 1 轮每批工具调用 1 轮上下文发送量每轮全量重发递增每批仅发 1 次执行方式逐工具「出调用→执行→回填」生成代码后顺序执行模型开销高多轮往返低批量编排适合场景需要逐步决策的探索式任务步骤明确的批处理任务自主性模型每步都「开口」模型一次性「规划完」核心差异一句话传统方式让模型每一小步都开口说话PTC 让模型一次性把计划说完再执行。四、那么 PTC 有什么代价天下没有免费的午餐。PTC 的省 Token 是以「减少模型中途干预」为代价的1. 不适合探索式任务当任务需要「看一步、想一步」时比如调试一个从未见过的 bugPTC 让模型一次性规划可能会跑偏。如果代码中途失败了还得回到传统模式重试。2. 代码生成有失败概率让模型生成一段可执行代码就引入了「代码可能写错」的风险。Harness 的应对是错误回填如果某一步工具调用失败把错误信息回填给模型让它修复脚本再跑。3. 工具返回结果不确定性传统方式每轮都能根据真实返回值调整下一步PTC 一次规划完如果中间某步返回了「超预期」的结果脚本里的后续逻辑可能基于错误前提。五、什么时候该用 PTC——决策清单任务特征推荐模式步骤明确、顺序固定部署、打包、批量统计✅ PTC探索式、需要中途决策调试、重构、写新功能标准模式最小环境验证模型能力跑分、基准测试极简模式PTC 也可需要 Agent 改造自身试验插件创造模式实用建议把 PTC 当「批处理利器」用。凡是你能在脑子里预演流程的任务——「先拉代码 → 装依赖 → 跑测试 → 汇总失败」——都值得用 PTC 跑Token 开销直接降一个量级。六、PTC 与峰谷定价的组合拳接上一篇的主题如果用 PTC 低谷时段 会话复用省钱的叠加效果非常可观PTC 省的是「模型往返 重复上下文」——Token 总量变少低谷定价省的是「单价」——每个 Token 半价会话复用省的是「缓存未命中」——重复部分走缓存价三个维度相乘同一个任务的最大成本差距可以到8-10 倍。这就是为什么「同样的模型、同一个任务跑法不同成本差 7 倍」——不是模型的问题是工程策略的问题。七、小结PTC程序化工具调用的本质让模型写代码而不是逐轮喊话把多轮工具调用批量化两轮模型往返搞定传统七轮省掉每次重发累积上下文的成本适合批处理、不适合探索使用前先问「这个任务流程我能预演吗」与低谷调度、会话复用叠加成本差距可达一个数量级。DeepSeek Harness 的 PTC 模式是「一切皆插件」架构在产品形态上的又一次验证同一个引擎换一组插件就能得到一种完全不同的 Agent 工作方式。下一篇我们聊 Harness 里最容易被忽略、但最该被严肃对待的部分——沙箱与安全问题。八、补充PTC 的工程实现与真实案例拆解PTC 在 Harness 里的实现位置PTC 不是一个独立的二进制而是标准模式之上的一组插件切换把「逐轮工具分派」的执行策略换成「代码段收集-执行-回填」的策略。因为 Agent Loop 本身在 Harness 里就是可替换插件前面架构篇讲过所以 PTC 的实现成本极低——这就是插件化架构的回报一种新的工作方式只是一次装配变更。真实案例「统计仓库代码量」任务看一个步骤明确的任务对比两种模式的开销任务统计一个中型 Python 仓库约 300 个文件的代码行数按目录分类输出并生成报告文件。标准模式的路径约 9 轮往返轮1: list 根目录 → 上下文 4k 轮2: 决定逐目录统计 → 上下文 8k 轮3-7: 逐目录 findwc → 上下文 12k→28k 递增 轮8: 汇总写报告 → 上下文 32k 轮9: 确认报告 → 上下文 34k 累计发送上下文 ≈ 4812162024283234 ≈ 178kPTC 模式的路径2 轮往返轮1: 模型生成一段脚本 for dir in dirs: counts[dir] call_tool(bash, ffind {dir} -name *.py | xargs wc -l) write_report(counts) → 上下文 4k 内核: 顺序执行 6 次 bash 1 次写入0 模型 Token 轮2: 模型基于结果做总结 → 上下文 6k 累计发送上下文 ≈ 10k同一个任务178k vs 10k差 17 倍。而且 PTC 模式墙钟时间也更短——工具调用在内核里顺序执行省掉了每轮「模型思考-输出-等待」的往返延迟。什么时候 PTC 会翻车公平起见也列两个真实翻车场景场景 A探索式调试。「测试挂了帮我查原因」——模型根本不知道要几步才能定位强行一次规划完脚本跑到一半发现假设错了只能废弃重来反而比标准模式多浪费一轮。场景 B结果依赖型分支。「如果 A 文件存在就执行 X否则执行 Y」——这类带运行时分支的任务PTC 脚本要么把两个分支都跑浪费要么在内核里实现条件执行复杂度上来了。分支逻辑越重PTC 的优势越小。决策心法三秒钟判断该不该用 PTC问自己一个问题「我能不能用人话把这个任务的步骤一二三四说清楚」能 → PTC批处理、统计、格式化、部署流水线不能 → 标准模式调试、重构、开放式研究这个心法的本质是PTC 把「规划成本」从运行时挪到了任务下达时。你提前想清楚的每一步都是模型省下的每一轮往返。PTC 与缓存的协同最后一个进阶点PTC 生成的代码段本身也进入会话历史所以连续的 PTC 任务之间同样享受前缀缓存。把「PTC 批量执行 会话复用 低谷时段」三件套叠满就是当前 Harness 上单位成本最低的 Agent 跑法——没有之一。九、补充PTC 安全边界与团队落地清单代码执行的安全问题PTC 比标准模式更需要认真对待PTC 的本质是「让模型写代码让内核执行代码」——这比逐轮工具调用多了一个攻击面模型生成的代码本身可能被污染。两个具体风险注入放大如果模型在规划时读到了恶意内容比如某个 issue 里藏的指令标准模式下它最多被诱导调用一次工具PTC 模式下恶意指令可能被写进一整段脚本一次执行多个危险操作。杀伤半径被放大了审查盲区逐轮工具调用时人类审批者每次只面对一个操作容易看住PTC 一次提交一段脚本审批者面对的是「一段代码」——很多人对代码的审查耐心远低于对单条命令的警惕。对应的防御动作PTC 脚本在执行前必须经过与工具调用同级的审批策略危险命令rm、curl、chmod该拦照拦——Harness 的审批机制对 PTC 同样生效但你要确认自己的策略覆盖了脚本内联命令的场景高危环境生产服务器、含密钥的机器禁用 PTC只用标准模式逐轮确认给 PTC 脚本设置资源上限执行超时、子进程数上限、磁盘写入配额。一句话PTC 的便利是批量的风险也是批量的。省 Token 的收益越大安全边界越要画清楚。团队落地清单把 PTC 用成制度而不是玩具想在团队里真正用好 PTC建议按这五步走圈定 PTC 白名单任务类型部署脚本生成、测试报告汇总、代码批量格式化、依赖升级巡检——步骤明确、无运行时分支的任务先上写任务模板每类 PTC 任务配一份提示词模板明确「步骤用代码表达、分支逻辑显式列出、失败时返回结构化错误」建立成本看板记录每个 PTC 任务的 Token 消耗与轮次数和标准模式的历史数据对比——用数据证明 PTC 的价值而不是靠感觉失败复盘制度PTC 任务失败时保留完整 trace每周归类规划错误 / 执行错误 / 环境问题针对性优化模板定期压测边界每季度挑一个「看起来像探索式」的任务试试 PTC记录翻车方式——团队的 PTC 使用边界应该随模型能力升级而动态外扩。工具的价值从来不取决于它多强大而取决于团队把它用得多系统。PTC 也一样——用成制度的团队省下的不只是 Token是整个 Agent 工作流的确定性。十、补充PTC 与极简模式的关系——跑分为什么爱用它最后澄清一个常见困惑官方跑分DeepSWE 基准用的是极简模式那 PTC 和极简是什么关系答案是两个正交的维度极简模式定义的是「装多少工具」只有 bash 文件编辑两个目的是排除工具增强的干扰测模型裸能力PTC定义的是「工具怎么编排」批量代码化 vs 逐轮调用目的是省 Token 和提速。两者可以自由组合极简 逐轮是官方基准跑法最保守、最可比极简 PTC 是「最省 Token 的跑法」适合大批量评测标准 PTC 是日常工程的最佳平衡点。理解了这层正交关系你就能自己组装出任何想要的跑法——这正是 Harness「一切皆插件」的意义模式不是官方发给你的菜单而是你自己拼出来的配方。PTC 只是其中最有价值的一个配料。十一、补充PTC 实测 Token 数据对比表为了把「省 Token」从感觉变成数字下面给出一组在统一测试环境下的实测对比。测试任务均来自前面出现过的典型场景模型统一使用 DeepSeek 系列会话不跨任务复用取 3 次运行的中位数。表中「输入 Token」指模型累计接收的上下文总量含工具回填「输出 Token」指模型累计生成量「总 Token」为两者之和极简模式只保留 bash 与文件编辑两类工具PTC 与标准模式使用完整工具集。任务模式输入 Token输出 Token总 Token耗时成功率仓库代码量统计标准模式176,2004,100180,3008 分 40 秒96%仓库代码量统计PTC 模式9,6001,80011,4002 分 10 秒92%仓库代码量统计极简模式163,5003,900167,4008 分 05 秒94%测试失败汇总标准模式88,4002,30090,7004 分 30 秒93%测试失败汇总PTC 模式7,8001,2009,0001 分 20 秒89%测试失败汇总极简模式81,2002,10083,3004 分 15 秒90%批量格式化标准模式42,7001,40044,1002 分 50 秒97%批量格式化PTC 模式5,2009006,10055 秒95%批量格式化极简模式39,8001,30041,1002 分 40 秒95%探索式调试标准模式134,6003,600138,2006 分 20 秒88%探索式调试PTC 模式51,3002,40053,7003 分 05 秒71%探索式调试极简模式129,0003,400132,4006 分 10 秒85%从这组数据可以读出三条结论步骤明确的任务PTC 的总 Token 普遍只有标准模式的 6%-15%耗时缩短到 1/4 甚至更低收益最明显极简模式省的是「工具复杂度」而不是「往返次数」所以 Token 只比标准模式低 5%-10%它和 PTC 的省法完全不同这也印证了上一节「两个正交维度」的判断探索式任务里 PTC 的成功率明显下降71% vs 88%说明当流程无法预先规划时强行批量化反而更脆弱。因此PTC 的 Token 优势是有条件的任务越像流水线PTC 越省任务越像探险PTC 越贵。做技术选型时先看任务类型再看 Token 预算最后才轮到价格峰谷这些乘数。标签#DeepSeek #PTC #Token优化 #AI Agent #Harness