DeepSeek Harness 的讨论逐渐从“它支持哪些模型”转向“Agent 如何更高效地使用工具”。其中PTC 模式通过 Code Mode SDK 让模型生成一段程序组合多次工具调用再把结果交回运行时。创源 AIGC 在本文中只作为一个可替换的外部模型节点出现重点不在服务介绍而在于 PTC/Code Mode 到底解决了什么问题、又把什么风险集中到了一次执行里。本文讨论真实的 AI、AIGC 和 IT 研发场景标准模式、PTC 模式和极简模式怎样选择如何用一个接口改造案例比较它们以及如何设置超时、权限、回放和人工停止条件。文章适合使用 Codex、Claude Code、VSCode AI 插件、Ollama 或 LiteLLM正在评估 Coding Agent 运行效率的开发者。截至 2026 年 8 月 17 日DeepSeek Harness 仍属于开发者预览项目。公开说明将 PTC 模式描述为具备标准模式的工具能力并通过 Code Mode SDK 呈现工具让模型用一个 TypeScript 程序组合多步操作。这个描述足以说明设计方向但不足以保证每个版本的 API、权限和执行细节都相同。下文中的代码均为解释机制的示意实际接入时仍要对照当前版本文档和本地测试结果。一、PTC 不是“更强的 Agent”而是换了一种调用工具的方法传统 Agent Loop 通常是这样的模型先选择一个工具运行时执行工具并返回结果模型读取结果后再选择下一个工具。一次代码任务可能要经历搜索文件、读取文件、运行测试、查看输出、读取另一个文件、再次运行测试等多轮往返。每一轮都要重新编码上下文、等待响应、记录事件和判断下一步。PTC 模式改变的是调用形态。模型不再只提交“下一步调用哪个工具”而是可以生成一段程序在程序中组合多个工具操作。程序负责遍历文件、筛选结果、汇总输出或按条件继续执行运行时负责执行这段程序并返回结果。这样可以减少模型与工具之间的往返也能把简单的控制流从自然语言决策交给代码。但 PTC 不会自动提升模型的判断能力。它只是把多步操作包装得更紧凑。模型仍然可能写错路径、误解接口、遗漏边界区别在于一次错误可能影响一串调用。原来模型选错一个工具通常只造成一次失败现在模型生成的程序如果循环条件、参数或过滤规则错误可能读取更多文件、执行更多命令甚至把错误结果传给后续步骤。因此PTC 的核心问题不是“能不能写程序”而是“生成的程序拥有什么能力”。需要同时关注四个方面程序能调用哪些工具工具参数是否再次经过策略校验。程序能访问哪些文件、进程、网络和环境变量。程序执行多少步失败后是否停止是否允许重试。运行时如何记录程序本身、每次子调用和最终结果。如果这些问题没有答案PTC 只是把一堆隐含调用放进一个更难审查的黑盒。相反如果每个子调用仍然经过权限、超时和事件控制PTC 才有机会成为一种更高效的 Agent Loop。还可以把普通工具调用和 PTC 看成两种不同的状态机。普通模式在每个状态之间都经过模型判断优点是每一步都能重新解释缺点是往返多、上下文重复。PTC 把一部分状态转换固化为程序优点是循环和过滤更快缺点是程序生成时的假设会贯穿后续状态。选择哪一种取决于任务中的“不确定性”分布不确定性集中在开始阶段时可以先让模型判断再把稳定步骤交给程序不确定性分散在每个文件和每个业务规则里就不应过早组合。在实际工程里我会给工具调用设置三种预算调用数量预算、数据读取预算和副作用预算。调用数量预算限制程序最多执行多少个子工具数据读取预算限制总字节数和单文件大小副作用预算则默认是零只有经过人工批准才允许写入或联网。预算不是为了追求一个漂亮数字而是为了在程序失控前给运行时一个明确的中断点。二、为什么普通 Coding Agent 会被工具往返拖慢在编辑器里完成一个小函数时工具往返通常不明显。但跨文件任务会不断产生上下文切换。模型需要先定位入口再读取实现再搜索调用方再查看测试再运行命令。任何一步输出过长、文件过多或命令失败都会增加下一轮输入。工具往返至少带来五类成本。上下文重复每一轮模型都要重新看到任务目标、已完成步骤、文件片段和工具输出。即使运行时做了压缩也可能丢失关键细节或者把旧结论与新结果混在一起。决策延迟每次工具调用后模型都要等待结果再决定下一步。对需要遍历几十个文件的任务而言单次决策的延迟会被放大成一长串等待。中间结果膨胀搜索命令可能返回大量无关行测试报告可能包含重复堆栈。若每一轮都把原始输出送回模型Token 和人工排查成本都会增加。状态恢复困难如果浏览器断开、进程重启或模型请求超时运行时需要判断哪些工具已经执行哪些结果已经写入。没有明确的事件编号时重复执行可能产生重复副作用。错误传播上一轮的错误路径可能被当成下一轮事实。例如搜索命令因为工作目录错误没有找到文件模型却把“没有结果”理解成“项目不存在”继续生成错误计划。PTC 可以把其中一部分控制流放到程序中程序一次读取白名单文件过滤出相关内容运行检查再返回压缩后的摘要。模型不必为每个文件单独作出决策。但这并不意味着所有任务都应该使用 PTC。只有那些步骤可预测、数据边界稳定、失败可以分类的流程才适合将控制流程序化。三、Code Mode 的价值来自可组合性风险也来自可组合性下面用一个简化的伪代码说明 PTC 的思路。它不是 DeepSeek Harness 的官方接口只表示模型生成的程序可能如何组合工具constfilesawaittools.listFiles({root:src,pattern:**/*.ts,maxItems:80});constcandidatesfiles.filter((file)file.path.includes(orders)||file.path.includes(pagination));constreports[];for(constfileofcandidates){consttextawaittools.readFile({path:file.path,maxBytes:20000});reports.push(awaittools.inspectContract({path:file.path,text}));}return{files:candidates.map((item)item.path),reports,next:reports.some((item)item.statusunknown)?pause-for-human-review:continue};这段程序看起来比多轮自然语言调用更直接但运行时不能因为它是“模型生成的程序”就跳过检查。listFiles应再次检查根目录和数量上限readFile应验证路径和大小inspectContract应检查输入 Schema循环应有最大迭代次数。即使程序最后返回continueHarness 也要根据自己的策略确认是否真的允许继续。PTC 的优势主要有三点。第一可以把过滤、遍历和汇总等机械控制流写成程序减少模型往返。第二程序结构本身可以被静态分析例如检查是否存在未授权工具、无限循环、动态路径拼接和外部网络请求。第三程序输出可以设计成结构化对象减少自然语言上下文对下一轮的干扰。PTC 的风险也有三点。第一模型可能把一个本来只读的任务组合成写操作或者通过工具参数间接扩大读取范围。第二错误会沿程序路径传播一个错误条件可能触发多次调用。第三开发者可能只审查最终结果没有审查模型生成的程序和每个子调用。因此Code Mode 的安全边界应当采用“双重校验”模型生成程序前系统提示和工具描述说明允许的能力程序执行时运行时对每一个实际调用再次执行路径、参数、权限、资源和超时检查。前一层防止模型误解后一层防止模型绕过。在双重校验之外还可以增加一个“能力降级”步骤。模型生成的程序先被解析成一个有限的中间表示只保留允许的操作例如列出文件、读取片段、运行固定检查和返回结构化结果动态导入、任意网络请求、环境变量读取、进程创建和自定义 Shell 字符串则直接拒绝。只有通过降级和静态检查的程序才进入真正的执行器。这样做会牺牲一部分灵活性但能把 PTC 从“运行任意模型代码”变成“运行受限的任务计划”。程序输出也应分成两层。第一层是机器可验证的结果例如文件列表、退出码、检查状态和事件编号第二层才是交给模型阅读的摘要。若第一层不完整第二层不能自行补全。这个顺序很重要因为自然语言摘要很容易把“没有检查到”写成“没有问题”。四、案例同一个接口改造任务三种模式如何分工为了比较 PTC 的实际价值我准备一个订单服务改造任务新增按更新时间过滤和分页查询保持旧客户端行为补充测试和接口文档。项目使用 TypeScript 服务、现有 API Schema 和一组脱敏请求样例。任务不涉及生产数据库也不允许修改部署文件。极简模式先建立人工基线极简模式只提供持久 Shell 和文件编辑。第一轮由开发者手动查看目录明确入口文件和测试命令模型只负责解释局部函数、提出测试样例和生成小范围补丁。极简模式的优势是边界很小。每次动作都容易追踪模型无法自动搜索整个仓库也不容易因为一个错误计划读取无关目录。它的缺点是工具往返较多开发者需要手动提供上下文跨文件任务耗时更长。我会把极简模式作为基线而不是把它当作低级方案。只有先知道人工完成任务需要多少文件、多少次检查和多少次决策后面比较 PTC 才有意义。否则工具调用减少了也无法确认是否真的减少了返工。标准模式观察完整 Agent 的行为标准模式提供文件编辑、Shell、检索、Skills、计划、目标、子 Agent 和工作流。它适合观察完整 Coding Agent 如何拆解任务但需要严格限制工作目录和网络出口。在这个案例里标准模式可以先生成计划搜索所有订单相关文件读取调用方再提出代码和测试修改。它的优势是探索能力强遇到未知仓库结构时更容易找到相关信息缺点是工具选择次数多轨迹较长模型可能把不相关文件带进上下文。标准模式的验收指标不应只有“最终测试通过”。还要记录读取文件数量、修改文件数量、无关工具调用、被拒绝的调用和人工返工。若它读取了大量不相关文件说明上下文过滤不够若它频繁修改又回退说明计划或停止条件有问题。PTC 模式把稳定控制流组合起来在完成一次标准模式运行后我会把已经确认的步骤提炼成 PTC 程序列出变更相关文件读取接口定义和测试运行规则检查汇总风险再把摘要交给模型决定是否需要人工确认。PTC 不负责猜测业务规则只负责组合已知工具和确定性步骤。示意流程如下读取任务契约 - 列出允许目录下的候选文件 - 根据路径和内容过滤订单相关文件 - 读取接口 Schema、测试和脱敏样例 - 运行静态检查与 git diff --check - 汇总结果并限制输出大小 - 若存在未知项暂停并等待人工 - 否则把结构化摘要交给模型生成计划这时 PTC 的作用是减少重复搜索和多轮摘要不是让模型拥有更大权限。它仍然只能读取白名单目录不能修改文件也不能访问网络。等人工确认分页默认值和兼容性要求后再由独立的写入工具处理最小补丁。案例中有一个很容易被忽略的顺序问题分页默认值、空结果响应和旧客户端兼容性都属于业务事实不属于代码搜索能够推导出的结论。因此PTC 程序只能把相关证据汇总出来不能替产品或维护者做决定。程序发现接口 Schema 与旧测试不一致时应该返回pause-for-human-review如果它自行选择一个默认值并继续生成补丁工具往返虽然减少了错误责任却被隐藏了。为了观察这一点我会准备三组输入。第一组是规则明确、测试完整的正常任务第二组缺少一个关键事实例如没有说明分页默认值第三组包含互相矛盾的 Schema 和测试。PTC 预期的结果不是三组都生成代码而是第一组继续、第二组暂停、第三组报告冲突。只有这样程序化控制流才没有把“未知”压缩成“通过”。对照结果应该看什么三种模式的比较可以整理成一张记录表指标极简模式标准模式PTC 模式工具往返通常较多较多且有探索性对稳定步骤可减少未知仓库适应性依赖人工提供上下文较强依赖预先定义的程序权限面最小较大取决于程序和子工具轨迹长度短但分散长且细节多程序级加子调用级错误传播单步为主多轮传播可能在循环中放大适合任务小范围修改、基线探索未知仓库稳定、重复、可回放流程这张表不能直接得出“PTC 更好”。如果任务每次都需要重新理解业务规则程序化控制流可能过早固化假设如果任务路径稳定且输入边界清楚PTC 才可能减少等待和重复上下文。对照时还要保留人工基线。假设极简模式需要开发者手动查看 12 个文件、运行 4 次测试标准模式自动读取 30 个文件PTC 只读取 8 个文件这些数字本身并不能说明 PTC 一定更优。还要看 8 个文件是否覆盖了真正的调用链标准模式是否发现了极简模式遗漏的边界以及人工最终修改了多少行。工具调用少可能代表过滤有效也可能代表程序过滤得过窄。可以把每次运行记录成“效率、质量、风险、维护”四组数据。效率记录耗时和调用数量质量记录测试、Schema 和人工修改风险记录拒绝调用、越界尝试和副作用维护记录模板修改、回放失败和升级耗时。连续跑一组固定任务后团队才能知道 PTC 是在减少工作还是把工作转移到了程序审查和故障排查。五、PTC 任务必须有三个停止点很多 Agent 工作流只在最终结果处设置人工审批但 PTC 更需要中间停止点。因为程序可能在模型再次看到结果之前已经完成多次工具调用错误一旦扩散后面再审批就晚了。输入停止点程序开始前运行时要检查任务的目录、数据等级、文件数量和输入哈希。如果输入包发生变化或者出现未经脱敏的日志任务应当暂停。不要让 PTC 自动把缺失的上下文补成“读取整个仓库”。能力停止点每次子调用前工具层检查路径、命令、网络和资源预算。程序可以请求readFile但不能通过路径拼接访问白名单之外的文件程序可以运行测试但不能把测试命令换成任意 Shell程序可以调用模型解释但不能把模型返回的字符串当作下一条命令执行。结果停止点程序完成后运行时检查输出 Schema、证据数量、状态值和副作用声明。若程序返回“通过”但没有测试报告或者返回的文件列表超出任务范围必须暂停。结果停止点可以避免一段语法正确的 Code Mode 程序把不完整事实包装成成功。这三个停止点应该写入事件流并区分“程序自行结束”和“运行时强制停止”。前者表示程序按条件完成后者表示策略发现风险或资源耗尽。两者如果都显示为done后续人工就无法判断任务到底是成功还是被系统截断。停止还需要考虑重试。网络请求失败可以在固定次数内重试但文件读取被拒绝、Schema 不合法和权限不足不应自动重试。测试失败也要区分环境故障和业务断言失败前者可以重新运行一次后者应当把失败报告交给模型或人工而不是让程序不断改写代码。重试策略必须写进工具契约不能让模型通过生成更多循环自行决定。如果 PTC 程序中存在并行调用停止条件还要处理已经启动的子任务。运行时需要能够取消尚未完成的进程收集已完成任务的结果并标记哪些结果被取消。否则一次超时只停止了外层程序后台子进程仍然可能继续读取文件、写入缓存或访问网络。并发能力越强取消和清理就越不能依赖进程自然退出。人工暂停也要成为一种正式状态而不是在 UI 上点一下就消失。暂停事件应该记录原因、当前程序位置、已完成的子调用、待确认问题和恢复条件。恢复时可以从检查点继续也可以创建一个分支重新执行不能在原事件流中悄悄替换任务目标。六、如何评估 PTC 带来的真实收益PTC 的收益不能只用工具调用次数衡量。减少调用可能只是把更多逻辑塞进一次程序也可能因为少了人工确认而增加返工。更合理的评估至少包括效率、质量、风险和维护四类指标。效率指标包括端到端耗时、模型请求次数、子工具调用次数、上下文输入量和重复读取比例。质量指标包括测试通过率、Schema 一致性、人工修改行数、误报和漏报。风险指标包括越界请求、被拒绝调用、网络访问、未声明副作用和失败后的重复执行。维护指标包括程序模板变更次数、升级回放失败数、插件依赖变更和人工排查时间。可以用一个简单的任务记录格式保存这些信息{task_id:order-pagination-2026-08-17,mode:ptc,program_revision:ptc-review-v3,model_alias:code-analysis,tool_calls:18,denied_calls:1,human_pauses:2,checks:{schema:pass,tests:pass,diff_scope:pass},final_state:accepted-with-follow-up}这里的数字只是记录格式示意不代表任何产品性能。真正比较时应固定任务样本、仓库版本、网络条件、模型别名和验收命令。一次任务很快不代表 PTC 长期有效一次任务失败也不代表所有 Code Mode 都不适合。需要观察多次回放中的趋势和失败类型。我尤其关注“程序生成后的人工作改量”。如果 PTC 让工具调用变少却让人工需要花更多时间阅读复杂程序和追查隐藏调用收益可能只是从机器时间转移到了审查时间。反过来如果程序短小、结构清晰、可以静态检查并且把确定性结果提前汇总PTC 才真正减少了重复劳动。还要测量“错误发现的时间”。普通模式可能在第二轮模型对话中发现路径错了PTC 则可能在程序结束后才暴露错误。如果错误更晚出现端到端耗时未必更短。一个有价值的 PTC 方案应该让错误更早进入结构化结果例如在第一次读取超出范围时立刻停止而不是继续执行剩余循环再统一报告。对于代码生成任务可以把最终补丁放到 PTC 之外。PTC 只负责准备上下文、运行确定性检查和生成计划真正的写入由受限编辑工具完成。这样可以把效率收益和高风险动作分开测量如果上下文准备明显变快但写入仍由人工批准团队能清楚知道收益来自哪里也不必因为 PTC 的实验而放宽代码仓库权限。如果任务涉及图片、文档或其他 AIGC 内容也可以使用同样的思路。PTC 负责整理素材清单、检查尺寸和生成元数据模型负责提出文案或变体人工负责版权、事实和发布判断。文本、代码和图片都可以共享运行轨迹但不应该共享相同的副作用预算。七、在线模型、本地模型与 PTC 的组合边界PTC 让模型可以生成更长的工具编排程序因此模型节点的输入和输出边界更重要。创源 AIGC 如果参与 PTC 工作流更适合承担计划解释、风险归纳或公开代码的结构分析不应直接决定任意命令、网络出口和文件权限。程序执行权必须由 Harness 和工具层控制不能因为模型能生成 TypeScript 就把它当作可信脚本。在一次非敏感的 PTC 兼容性观察中测试记录的接入地址为https://178.nz/yinc。该记录只说明测试入口不代表模型数量、价格、稳定性或服务等级。实际使用时应先把程序生成限制在脱敏输入和只读工具内再根据协议兼容性、延迟、上下文长度、日志保留和替代节点做判断。Ollama 可以提供本地模型LiteLLM 可以处理逻辑模型名、接口适配和基础请求治理Harness 则负责会话、工具、循环和事件。三者可以组合但不要让 PTC 程序绕过 LiteLLM 的密钥和限流也不要让网关承担插件沙箱和人工审批。每一层只负责自己的边界故障时才容易定位。如果在线节点不可用PTC 任务应该按预先定义的路径处理先尝试批准的替代模型若替代模型会改变数据等级或输出 Schema则只执行确定性检查如果程序本身依赖模型继续决策直接暂停并保存轨迹。不要把外部服务故障转换成“扩大权限以完成任务”。八、升级和回放PTC 程序本身也需要版本治理PTC 的一个新问题是除了 Harness、模型和插件需要版本化模型生成的程序模板和工具描述也需要版本化。同一段自然语言任务在工具签名变化后可能生成不同程序同一程序在权限策略变化后也可能出现不同执行结果。因此每次 PTC 运行至少保存四个版本Harness 版本、程序或提示模板版本、工具契约版本、模型逻辑别名。输入仓库和测试样例也要固定。升级时先执行只读回放再执行包含拒绝、超时、空结果和异常输出的故障样例。回放不能只比较最终文本。应该比较程序是否访问相同目录子工具数量是否突然增加拒绝事件是否消失输出 Schema 是否变化失败状态是否仍然可分类人工暂停点是否被跳过。措辞变化可以接受权限和证据变化不能被默认忽略。PTC 程序还要支持撤销。当发现某段程序存在无限循环、路径绕过或错误重试时可以通过程序版本或能力标识禁用它不必停掉所有 Harness 任务。历史轨迹保留原程序哈希和工具调用后续人工可以判断哪些任务受影响。对于开发预览版兼容性破坏尤其需要被纳入流程。不要直接把主分支变化同步到日常环境先锁定提交或预览版本保存当前配置和固定任务。升级前后都运行同一组案例确认标准模式、PTC 模式和极简模式至少还能完成各自的基线任务。工具签名变化时尤其要检查程序的隐式假设。例如旧工具把文件列表作为字符串数组返回新版本改成带有大小和类型的对象旧程序如果继续读取.path可能得到空值并触发错误过滤。升级回放应当对输入 Schema 做严格校验发现字段缺失就停止而不是让模型根据空结果自行猜测。程序模板也可能随着团队经验逐渐变长。模板越长覆盖的场景越多但模型越容易误用不相关的步骤。可以把模板拆成小的、版本化的能力片段例如只读审查、测试汇总、文档生成和差异统计分别维护任务启动时按契约组合而不是把所有能力写进一段巨型提示。这样升级某个片段不会影响全部任务。回放材料还应包含一次“反事实运行”在相同输入下撤掉某个工具或缩小目录权限确认任务会进入暂停或降级状态。如果程序在权限减少后仍然宣称完成说明它的输出没有真正依赖证据或者运行时没有把拒绝传播到最终状态。这个测试对发现隐式依赖很有帮助。九、什么时候应该使用 PTC什么时候保持普通工具调用适合 PTC 的任务通常有四个特征步骤重复出现输入边界稳定控制流可以被代码清楚表达失败后能够暂停或回滚。例如读取一组白名单文件、运行静态检查、汇总测试报告、生成结构化审查输入这些流程适合程序化组合。不适合 PTC 的任务也很明确。第一业务规则尚未确认程序容易把猜测固化。第二步骤包含高风险副作用任何批量循环都可能放大错误。第三输入结构高度不稳定程序模板维护成本超过工具往返成本。第四团队没有能力审查生成程序、工具契约和事件流。第五模型只是偶尔需要调用一个工具额外的 Code Mode 复杂度没有实际收益。可以采用渐进方式先用极简模式建立人工基线再用标准模式探索仓库最后只把稳定、低风险、可回放的步骤提炼成 PTC。每次新增一个工具或一个循环都增加对应的路径测试、参数测试、超时测试和回放样例。若 PTC 运行失败先回退到标准模式或人工流程而不是不断增加重试次数。最后可以用五个问题做判断这组步骤是否足够稳定能够写成清晰的程序程序中的每一次工具调用是否都能独立校验权限失败时能否停止在中间节点而不是继续循环是否保存了程序版本、工具版本和完整事件轨迹减少的模型往返是否真的超过了程序维护和人工审查成本如果答案是否定的普通工具调用可能更容易理解和维护。PTC 的价值不是让所有 Agent 都变成程序而是让那些已经稳定的控制流脱离自然语言往返成为可检查、可回放的执行单元。结语让程序承担控制流让模型承担判断让运行时承担边界DeepSeek Harness 的 PTC 模式值得关注不是因为它让 Agent 变成了一个更复杂的聊天窗口而是因为它把工具编排显式地放到了程序层。对于稳定的文件筛选、测试汇总和报告整理这种方式可能减少上下文重复和调用等待对于不稳定或高风险的任务它也可能放大一次错误绕过开发者原本能看到的中间步骤。创源 AIGC 可以作为外部解释节点Ollama 可以承担本地模型LiteLLM 可以处理接口适配Codex 或其他代码模型可以提供局部理解但 PTC 程序的权限、工具校验、停止条件和事件记录必须由 Harness 侧独立负责。模型可以提出程序不能因此获得程序之外的权限。真正稳妥的做法是先建立极简模式的人工基线再用标准模式观察真实任务最后只把稳定流程交给 PTC。让程序承担可预测的控制流让模型承担需要判断的部分让运行时承担权限、资源和证据边界PTC 才可能成为研发效率的增量而不是新的不可见风险。如果一次 PTC 运行不能解释自己读取了什么、为什么停下、哪些结果经过检查就算工具调用次数很少也不应把它视为成熟自动化。可解释的慢流程通常比无法回放的快流程更适合成为团队的长期基础。这条标准也适用于个人开发环境先保留人工接管再逐步放大程序化控制流逐步积累回放证据和失败样例避免盲目自动化和权限扩张。
