规划与执行分离：对话模型与编程代理协作实践

一、背景与痛点：能力错位与额度浪费并存

先看一个普遍存在的现状。多数开发团队如今同时拥有两类 AI 资源：

第一类是以对话见长的大模型服务。它擅长需求澄清、方案比较与任务拆解，尤其是高阶推理版本，不少使用者的共同感受是：面对跨模块重构、技术迁移这类复杂问题，它给出的规划条理清晰、层次分明、表述克制，不会贸然抛出过度设计。

第二类是深度集成到终端与 IDE 中的编程代理。它能直接读写仓库文件、运行测试与构建、管理分支与提交，是真正“能动手”的角色。

但把两者放在一起看，会发现三个尴尬的事实：

1. 对话模型“会想不会做”。它看不到你的真实仓库——文件树、分支状态、历史提交都不可见，所有判断都基于你手动粘贴的片段，上下文既不完整，也不持久。规划再漂亮，也无法在其基础上直接落地验证。
2. 编程代理“会做未必会想”。执行单点任务很可靠，可一旦需求膨胀为大型重构或多模块改造，任务拆解的质量就直接决定交付质量，拆解草率往往导致反复返工、改了东墙漏西墙。
3. 额度使用严重不均。编程代理的额度在重负载项目里常常捉襟见肘；而对话服务的额度，在大量使用者那里长期处于“日常问答用不完”的状态，白白闲置。

这三个问题指向同一个解法：把规划与执行拆开，分别交给最擅长的角色，并让两套额度各尽其用。

二、核心思路：一个负责想清楚，一个负责干活

方案的主干可以概括为一句话：让“会想”的模型读懂你的仓库并产出结构化计划，让“会做”的代理照着计划执行并回写结果。

拆开来看是四步：

1. 规划：对话模型以受控、只读为主的方式进入仓库，阅读文件树、关键源码、版本控制状态以及历史计划记录，输出结构化的任务计划。
2. 落盘：计划以文档形式写回仓库的约定目录，成为版本管理下的工程产物，而非聊天窗口里转瞬即逝的文本。
3. 执行：编程代理读取计划文件，逐任务改代码、写测试、跑构建。
4. 回写：执行结果、变更摘要与测试结论回写到计划目录，形成可追溯的闭环，并作为下一轮规划的输入。

这里的技术底座，是一类开放式的模型上下文协议标准：它为模型与外部系统（文件系统、版本库等）之间定义了标准化的工具接口，使得任何支持该类协议的模型，都能以一致、受控的方式访问外部数据源，而不必为每款模型单独编写集成代码。有了它，“让对话模型看见你的仓库”就从一个一次性难题，变成了标准化的工程问题。

三、技术架构：本地上下文服务 + HTTPS 安全隧道

整套架构由四个组件构成：

1. 本地上下文服务：在本机启动一个轻量服务，实现一组最小能力集的工具——列出文件树、读取指定文件、查询版本控制状态、读取与写入计划目录。注意，它只暴露你明确授权的能力，默认不提供任意命令执行。
2. HTTPS 安全隧道：对话模型运行在云端，天然无法访问你的内网机器。通过一条加密隧道把本地服务映射为公网可达的端点，并辅以访问令牌鉴权，远端模型即可安全调用本地工具。
3. 仓库侧约定：在仓库根目录约定一个计划目录（下文以 .plan/ 为例），存放目标说明、任务清单与执行记录。该目录纳入版本管理，规划与执行全过程因此可追溯、可 diff、可回滚。
4. 对话侧接入：在支持工具调用与外部服务接入的对话产品中，配置上述服务的端点与令牌，对话模型即获得“读仓库、写计划”的能力。

一次完整的数据流如下：

需求描述 → 对话模型按需读取仓库（文件树 / 关键源码 / 版本状态）→ 生成结构化任务计划并写入 .plan/ → 编程代理读取计划 → 逐任务执行并运行测试 → 回写执行日志 → 人工复核或由对话模型复盘

值得强调的是：两个 AI 之间不直接通信，一切信息都经由仓库中的结构化文档传递。这带来三个好处——过程可审计、中途可人工介入、事后可离线复盘。

四、工程约定：计划目录与任务清单设计

规划的价值不在于“聊出来的那段话”，而在于它能否变成执行方可消费的工程产物。一个可用的目录约定如下：

.plan/
  YYYY-MM-DD-payment-refactor/
    00-goal.md          # 目标、背景与约束（不改哪些、兼容性要求）
    tasks.md            # 任务清单，标注优先级与依赖
    execution-log.md    # 执行侧回写的进度、变更摘要与测试结果

tasks.md 建议采用带验收标准的任务结构：

# 任务清单：支付模块重构
- [ ] T1 梳理现有支付调用链路，列出全部入口
      验收：输出调用点清单并写入 00-goal.md 附录
- [ ] T2 定义统一的支付接口抽象（依赖：T1）
      验收：接口定义通过评审，不引入破坏性变更
- [ ] T3 改造三个调用方并补充单元测试（依赖：T2）
      验收：新增测试全部通过，现有回归用例不劣化
- [ ] T4 全量回归并更新文档（依赖：T3）
      验收：构建与回归通过，文档与代码一致

三条实践经验：

1. 任务粒度以“一次可验证的提交”为宜。过大，执行代理容易失控；过细，计划本身会膨胀到难以维护。
2. 每个任务写清验收标准，让执行结果可判定、可勾选，而不是“大概做完了”。
3. 要求规划模型先读历史计划与执行日志再规划，避免重复分析、重复产出相互矛盾的计划。

五、执行闭环：编程代理如何消费计划

执行侧可以固化为一个简单循环：

1. 读取 tasks.md，定位第一个未完成任务；
2. 依据任务描述与验收标准执行：修改代码、补充测试、运行构建；
3. 验证通过则勾选任务，并在 execution-log.md 记录变更摘要与测试结论；
4. 验证不通过则如实记录失败原因，标记阻塞，交由人工或规划侧介入；
5. 循环推进，直至清单完成，最后做一次整体回归。

这个循环既可以用命令行工具半自动推进（每步人工确认），也可以脚本化后在 CI 中定时触发。无论哪种形态，计划文件始终是唯一交接面——这意味着即使中途更换模型或工具，只要目录约定不变，工作流就不受影响。

六、额度经济学：让闲置额度转化为规划产能

这套架构还有一个常被忽视的经济性优势：对话服务与编程工具的额度，在多数产品形态下是两套独立账户、独立计费的。

• 规划消耗对话侧额度。对多数使用者而言，日常问答与写作根本用不满这部分额度，把结余用于项目规划，等于把闲置资源转化为生产力。
• 执行消耗编程工具侧额度，集中留给真正需要“动手”的改码、测试环节，单位额度的代码产出更高。

换个说法：规划阶段的长上下文、深度推理开销，由本就容易闲置的额度承担；执行阶段的高频小步调用，则落在额度效率最高的工具上。同等预算能支撑更复杂的项目——这正是“划算”的真正来源。

还有一个省额度的细节：规划阶段应引导模型“按需读取”而非“全量倾倒”仓库——先读文件树与说明文档，再按任务相关性挑重点文件读取。这既减少上下文开销，也降低无关信息对规划质量的干扰。

七、安全与合规要点

把本地仓库暴露给云端模型，安全是第一前提，建议守住四条线：

1. 传输与鉴权：隧道强制 HTTPS，本地服务配置访问令牌，避免端点被扫描滥用。
2. 能力最小化：规划模型保持只读为主，写入范围严格限定在计划目录白名单内；不授予修改源码或执行任意命令的权限。
3. 敏感信息治理：环境变量文件、密钥文件、含凭据的配置默认排除在可读范围之外，必要时先脱敏再暴露。
4. 流程不破例：计划目录纳入版本管理，执行侧的代码改动走正常工作流——分支、评审、合并。不因为“是 AI 做的”就绕过团队规范。

八、常见问题与对策

1. 计划与代码脱节：规划完成时代码仍在演进。对策是让执行侧在勾选任务前先做一次轻量 diff 检查，发现仓库已变更则回传规划侧更新计划。
2. 执行偏离计划：代理“顺手”改了计划外的东西。对策是在验收标准中明确改动范围，复核时用 diff 逐项核对。
3. 上下文预算膨胀：大型仓库全量读取既贵又慢。对策是分层读取——目录树 → 模块说明 → 关键文件，并让计划文件沉淀“本次任务相关文件索引”。
4. 额度仍然不够：往往说明执行侧承担了本可省掉的探索性工作。对策是把更多“试错”前移到规划阶段，用更便宜的对话额度完成方案取舍。

九、写在最后

“让最会想的模型负责想清楚，让最能干的代理负责干活”——这句话概括了整套方案的全部动机。它并不依赖任何特定产品：一个本地上下文服务、一条安全隧道、一份目录约定、一个执行循环，就是这个模式的全部组成。无论你的模型部署在本地，还是使用百度智能云等云平台托管的模型服务，该架构都同样成立。

如果你正被“编程工具额度不够用、对话额度用不完”困扰，或正在为大型重构的任务拆解质量发愁，不妨从给仓库加一个 .plan/ 目录开始：先把“计划”变成工程产物，再让执行侧照单干活。规划与执行的分离，很可能就是提升复杂任务交付质量的那个杠杆点。