一切皆在调度框架：如何优化你的 AI 调度配置

工程师们过去争论的是 IDE，如今争论的是调度框架（harness）。调度框架的本质是一个围绕大语言模型（LLM）的循环：while (have next message) do {tool}。一个流畅的调度框架能够极大地提升代码生成的速度和质量。

本文总结了优化调度框架的三个通用模式，这些模式仍然需要人工判断来执行。

保持 .md 文件精简且由人工编写

LLM 存在“指令预算”限制——前沿模型只能遵循几百条指令，之后便会进入“迟钝区”。过多的指令实际上会鼓励模型产生幻觉。全局系统提示（如 CLAUDE.md 或 AGENTS.md）应由人工编写，而非由 LLM 生成。ETH 的研究发现，LLM 生成的系统提示会降低性能，同时增加约 20% 的推理成本。描述项目的核心要求和最终用户即可，每个 token 都应争取其存在的价值。不要试图将所有规则都塞进提示中；相反，采用渐进式信息加载：仅在需要时让智能体拉取上下文，并通过描述性文件名让智能体知道有哪些可用信息。

对于 CLI，智能体可以通过运行 --help 发现子命令，而不是将所有文档都加载到上下文中。这对于模型从未见过的自定义内部工具尤为重要。技能（Skills）方面，行业已趋于一致：启动时只加载名称和描述，完整指令仅在智能体决定需要时才读取。MCP 工具同样需要选择性连接项目相关的服务器，并编写具体且关键词丰富的描述，以便基于搜索的发现机制能正常工作。

使用 R.P.I. 框架提升抽象层次

HumanLayer 提出的 R.P.I. 框架是一种有用的指导原则：每个提示在与调度框架交互时都应只做三件事之一：研究（Research）、规划（Plan）、执行（Implement）。研究阶段让智能体探索代码库结构，但不采取行动；规划阶段生成分步骤的执行计划，人工需主动审查；执行阶段在一个新的上下文窗口（主窗口）中按批准的计划实施。如果计划较长，可使用子代理模式，每个子代理有自己的会话，避免中间状态污染主上下文。

使用子代理维护干净的上下文

核心启发式原则是：当主智能体只需要子代理的工作总结时，就应该使用子代理。两种模式效果良好：并行扇出和流水线。并行扇出适用于调查和研究，例如当警报触发时，主智能体可以生成三个候选根因理论，并分别为每个理论启动一个子代理并行调查。流水线则通过顺序角色（如 UX 设计师、架构师、反对者）对功能进行多角度评估，每个阶段接收前一阶段的输出并添加分析。子代理不仅保持主对话干净，还将子代理自身保持在“聪明区域”，无需承载无关的早期信息。

结论

当调度框架在某个任务上失败时，很容易想切换框架。本文并非建议不体验各种工具，而是强调需要花时间真正适配一个框架到自己的工作流程中。不同框架有不同的约束、上下文窗口策略和工具路由逻辑；频繁切换意味着丧失配置文件中的机构知识，并从零开始积累失败案例。因此，建议选择一个覆盖团队大部分用例的框架（后续文章将讨论如何选择），并将每次失败视为数据点：记录在什么条件下哪个步骤出了什么问题，并相应调整 .md 文件和提示词策略。最好的调度框架是通过人工工程持续定制和迭代的框架。