第 05 章 · 四种模式不是等级，是四种用途

本篇目标：按任务性质选模式，而不是按熟练度。 原文最值得保留的一句判断：标准模式做事，PTC 模式编排，极简模式测量，创造模式改造。

5.1 先对齐命名（版本差异，别踩坑）

官方 官网中文页当前写「PTC 模式」；英文页仍保留 Code mode 的措辞，描述为「uses model-generated code to orchestrate multiple rounds of tool calls」。原文提到「Code 模式改名成 PTC 那次伴随了 session API 变化和 SQLite 后端移除」原文。

本文档统一称 PTC（Programmatic Tool Calling），对应早期文档里的 Code mode。读到 code 配置值时，指的就是它。native → code 是工具呈现模式的切换 原文。

5.2 四模式全表

官方 官网 + 原文 高阶指南，合并如下：

判据 6：四种模式是四套不同的 Harness 配置，不是同一个 Harness 的四个挡位。切换模式等于换掉模型所处的整个环境——这正是第 15 章「Harness 是评测变量」的直观证据。

5.3 标准模式：真正的高阶用法是「加刹车」

原文 给出的重构 + 测试闭环模板，价值在于四个人工刹车，可直接复制：

先读代码，不要修改任何文件。

第一步：运行测试套件，把当前失败/报错的测试完整列出来，作为基线。
第二步：定位导致这些失败的根因，逐个说明涉及哪些文件和函数。
第三步：给出重构方案，等我确认后再动手。

确认后执行时，每改完一个模块，必须重新运行一次相关测试。
如果测试没有从"失败"变成"通过"，立刻停下来告诉我，不要继续改下一个模块。

最后：输出一份改动清单，包含每个文件的改动原因和验证方式。

原文 标准模式的三个隐藏能力：

自定义斜杠命令本质：把每周都要重复描述的流程写成一条命令。原文给的 /repo 例子（显示当前分支与最近 3 次提交，非 Git 仓库给友好提示）。官方 架构表里有对应的正规入口：ctx.commands 注册，dsh 无需模型回合即可派发一个 human command。

5.4 PTC：省上下文的全部秘密在 return

原文 配置上只差一行：工具呈现模式 native → code，模型拿到 run_code 与生成的 SDK，通过 await tools.工具名(参数) 调用工具。

最小示意（沿用原文）：

// 通过 run_code 一次提交，在独立托管进程中执行
const readme = await tools.read_file({ path: "runoob-demo/README.md" }); // 只读，可并行
const intro  = await tools.web_search({ query: "RUNOOB 入门教程" });     // 与上一行无依赖

return {                       // ← 只有 return 的内容回到模型上下文
  brand: "RUNOOB",
  introCount: intro.results.length,
  readmeHead: readme.text.slice(0, 120),
};

两条执行语义 原文：

1. 程序运行在会话沙箱策略之下的独立托管进程，子调用仍走统一工具流水线，审批与钩子照常生效；
2. 独立只读调用可并行重叠（默认上限 10 路），会改动状态的操作按提交顺序单独执行。

判据 7（上下文经济学）：标准模式下，每一步的中间结果都要回到上下文，模型为它们付费；PTC 下中间过程在托管进程里跑完，只有 return 与日志回到模型。省 token 的不是代码，是「不把噪音送回模型」这个决定。

实测数据（实测）

原文注明任务为 3D 射击游戏。此表仅说明量级，不作为性能承诺；你必须在自己的题面上复现（第 15 章）。

该用 / 别用

原文定位：PTC 是「步骤多」任务的加速器，不是日常默认选项。

5.5 极简模式：受控环境，不是低配版

原文 常见误解对照：

保留的两个工具有讲究：持久化 bash（cd 一次状态保留，不用每次 cd xxx && ...）+ str_replace_editor（字符串替换式编辑）。

原文 引用 DataCamp：

"A benchmark score partly reflects the harness used for the test, not only the model."

并称 DeepSeek V4 Pro 官方跑分即用此模式作为框架。原文

第二用途：排查「到底是模型的问题还是环境的问题」——

在极简里能做、在标准里做不了  → 问题在环境（工具 schema 歧义 / 提示词冲突 / 压缩搞乱）
在极简里也做不了              → 问题在模型

第 06 章把这条展开成完整决策表。

原文结论：图快用极简，图稳用标准。

5.6 创造模式：工作对象是 Harness 自己

原文 四项能力：

官方 官网给出的 Creator 定义与此一致：inspect the current runtime, test Cordis plugins in memory, and combine them into new modes。

标准工作流 原文：

需求 → 调研运行时 → 写插件 → 内存试跑 → 你反馈 → 再改 → 固化为预设

反馈纪律：出问题时描述现象、别下结论。「点击没反应」✅ /「你写错了」❌。这与第 07 章「记录 exact symptom」是同一条方法论。

固化后的例子：写作模式、数据分析模式。第 13 章给出 cordis.patch.yml 的真实做法。

5.7 选型决策树

这个任务的目的是什么？
├─ 改代码 / 查资料 / 写文档 ──────────────→ Standard
├─ 评测模型能力 / 排查模型还是环境 ────────→ Minimal
├─ 造插件 / 造界面 / 造新模式 ────────────→ Creator
└─ 多步骤、逻辑固定、中间结果不用看？
    ├─ 只读多、可并行、上下文已很长 ──────→ PTC
    └─ 需要中途决策 / 大量有状态写操作 ──→ Standard
        并叠加：/plan 先确认，/goal 挂目标，/compact 控上下文

每天自动出报告？
└─ Standard + subagent 并行抓取 + schedule_create 定时投递（见第 14 章）

5.8 本章产出与验收

核心产出：四个模式各跑一个真实任务，记录耗时、工具调用数、输入 token、结果是否达标。

验收点：

• 能解释为什么「四种模式」不是难度等级
• 能说出 PTC 省 token 的机制，而不只是背「快 7 分钟」
• 能列出极简模式砍掉的 7 项能力，并解释为什么连「时钟上下文」都要砍
• 能用那套二分法，判断一次失败属于模型还是环境
• 能说出 native / code 与 Code mode / PTC 的对应关系

延伸阅读