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 的核心问题不是“能不能写程序”，而是“生成的程序拥有什么能力”。需要同时关注四个方面：

1. 程序能调用哪些工具，工具参数是否再次经过策略校验。
2. 程序能访问哪些文件、进程、网络和环境变量。
3. 程序执行多少步，失败后是否停止，是否允许重试。
4. 运行时如何记录程序本身、每次子调用和最终结果。

如果这些问题没有答案，PTC 只是把一堆隐含调用放进一个更难审查的黑盒。相反，如果每个子调用仍然经过权限、超时和事件控制，PTC 才有机会成为一种更高效的 Agent Loop。

还可以把普通工具调用和 PTC 看成两种不同的状态机。普通模式在每个状态之间都经过模型判断，优点是每一步都能重新解释，缺点是往返多、上下文重复。PTC 把一部分状态转换固化为程序，优点是循环和过滤更快，缺点是程序生成时的假设会贯穿后续状态。选择哪一种，取决于任务中的“不确定性”分布：不确定性集中在开始阶段时，可以先让模型判断，再把稳定步骤交给程序；不确定性分散在每个文件和每个业务规则里，就不应过早组合。

在实际工程里，我会给工具调用设置三种预算：调用数量预算、数据读取预算和副作用预算。调用数量预算限制程序最多执行多少个子工具；数据读取预算限制总字节数和单文件大小；副作用预算则默认是零，只有经过人工批准才允许写入或联网。预算不是为了追求一个漂亮数字，而是为了在程序失控前给运行时一个明确的中断点。

二、为什么普通 Coding Agent 会被工具往返拖慢

在编辑器里完成一个小函数时，工具往返通常不明显。但跨文件任务会不断产生上下文切换。模型需要先定位入口，再读取实现，再搜索调用方，再查看测试，再运行命令。任何一步输出过长、文件过多或命令失败，都会增加下一轮输入。

工具往返至少带来五类成本。

上下文重复

每一轮模型都要重新看到任务目标、已完成步骤、文件片段和工具输出。即使运行时做了压缩，也可能丢失关键细节，或者把旧结论与新结果混在一起。

决策延迟

每次工具调用后，模型都要等待结果再决定下一步。对需要遍历几十个文件的任务而言，单次决策的延迟会被放大成一长串等待。

中间结果膨胀

搜索命令可能返回大量无关行，测试报告可能包含重复堆栈。若每一轮都把原始输出送回模型，Token 和人工排查成本都会增加。

状态恢复困难

如果浏览器断开、进程重启或模型请求超时，运行时需要判断哪些工具已经执行，哪些结果已经写入。没有明确的事件编号时，重复执行可能产生重复副作用。

错误传播

上一轮的错误路径可能被当成下一轮事实。例如搜索命令因为工作目录错误没有找到文件，模型却把“没有结果”理解成“项目不存在”，继续生成错误计划。

PTC 可以把其中一部分控制流放到程序中：程序一次读取白名单文件，过滤出相关内容，运行检查，再返回压缩后的摘要。模型不必为每个文件单独作出决策。但这并不意味着所有任务都应该使用 PTC。只有那些步骤可预测、数据边界稳定、失败可以分类的流程，才适合将控制流程序化。

三、Code Mode 的价值来自可组合性，风险也来自可组合性

下面用一个简化的伪代码说明 PTC 的思路。它不是 DeepSeek Harness 的官方接口，只表示模型生成的程序可能如何组合工具：

const files = await tools.listFiles({
  root: "src",
  pattern: "**/*.ts",
  maxItems: 80
});

const candidates = files.filter((file) =>
  file.path.includes("orders") || file.path.includes("pagination")
);

const reports = [];
for (const file of candidates) {
  const text = await tools.readFile({ path: file.path, maxBytes: 20000 });
  reports.push(await tools.inspectContract({ path: file.path, text }));
}

return {
  files: candidates.map((item) => item.path),
  reports,
  next: reports.some((item) => item.status === "unknown")
    ? "pause-for-human-review"
    : "continue"
};

这段程序看起来比多轮自然语言调用更直接，但运行时不能因为它是“模型生成的程序”就跳过检查。listFiles 应再次检查根目录和数量上限，readFile 应验证路径和大小，inspectContract 应检查输入 Schema，循环应有最大迭代次数。即使程序最后返回 continue，Harness 也要根据自己的策略确认是否真的允许继续。

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 运行失败，先回退到标准模式或人工流程，而不是不断增加重试次数。

最后可以用五个问题做判断：

1. 这组步骤是否足够稳定，能够写成清晰的程序？
2. 程序中的每一次工具调用是否都能独立校验权限？
3. 失败时能否停止在中间节点，而不是继续循环？
4. 是否保存了程序版本、工具版本和完整事件轨迹？
5. 减少的模型往返，是否真的超过了程序维护和人工审查成本？

如果答案是否定的，普通工具调用可能更容易理解和维护。PTC 的价值不是让所有 Agent 都变成程序，而是让那些已经稳定的控制流脱离自然语言往返，成为可检查、可回放的执行单元。

结语：让程序承担控制流，让模型承担判断，让运行时承担边界

DeepSeek Harness 的 PTC 模式值得关注，不是因为它让 Agent 变成了一个更复杂的聊天窗口，而是因为它把工具编排显式地放到了程序层。对于稳定的文件筛选、测试汇总和报告整理，这种方式可能减少上下文重复和调用等待；对于不稳定或高风险的任务，它也可能放大一次错误，绕过开发者原本能看到的中间步骤。

创源 AIGC 可以作为外部解释节点，Ollama 可以承担本地模型，LiteLLM 可以处理接口适配，Codex 或其他代码模型可以提供局部理解，但 PTC 程序的权限、工具校验、停止条件和事件记录必须由 Harness 侧独立负责。模型可以提出程序，不能因此获得程序之外的权限。

真正稳妥的做法，是先建立极简模式的人工基线，再用标准模式观察真实任务，最后只把稳定流程交给 PTC。让程序承担可预测的控制流，让模型承担需要判断的部分，让运行时承担权限、资源和证据边界，PTC 才可能成为研发效率的增量，而不是新的不可见风险。

如果一次 PTC 运行不能解释自己读取了什么、为什么停下、哪些结果经过检查，就算工具调用次数很少，也不应把它视为成熟自动化。可解释的慢流程，通常比无法回放的快流程更适合成为团队的长期基础。

这条标准也适用于个人开发环境：先保留人工接管，再逐步放大程序化控制流，逐步积累回放证据和失败样例，避免盲目自动化和权限扩张。