调度harness工程｜Kimi K3作为内核，一套配置打造可移植 AI 智能体
内容提要
文章提出“调度框架工程”概念，认为提示词、上下文、工具、循环、图、评估等工程属于同一系统。调度框架包裹大模型，包含工具、权限、校验、定时与终止条件，是唯一不随模型版本变动的部分。作者以Kimi K3为内核，用一份yaml配置和钩子脚本搭建可移植智能体，支持300并发、夜间自动运行，并通过替换模型测试检验框架质量。
延伸解读
调度框架：模型迭代中的稳定层
文章指出，底层大模型迭代频繁，一次更新可能让排行榜名次跃升17位。若将业务逻辑塞进提示词，换模型后同一段文字可能被理解成不同含义。调度框架包裹模型，包含工具、权限、校验、定时与终止条件，是唯一不随模型版本变动的部分。把模型抽象成一行配置，框架其余部分保持稳定，就能在模型更新时快速迁移，避免重构整套系统。
权限与校验：夜间自动运行的前提
文章强调，权限配置优先级高于工具列表，明确智能体可写目录和高危操作需人工确认，是区分“可放心后台整夜跑”和“必须人盯着”的分水岭。校验器独立于智能体之外，脚本校验拦截格式错误，独立智能体复核避免自评放行。配合pre_tool钩子拦截越权写入、post_tool钩子丢弃格式错误输出，系统才能在无人值守时安全运行。
模型替换测试：检验框架可移植性
文章提出，检验智能体系统质量最快的方法是只修改model一行配置并重跑任务。若换模型后出现输出格式不稳定、任务不会自动停止、历史修正规则丢失、实体重复录入或越权写入，说明相关逻辑原本错误地写在了提示词或对话历史里。正确做法是将这些逻辑外移到数据结构、停止条件、CONSTRAINTS.md、别名表和权限钩子中。能通过替换测试的框架才具备可移植性。
成本与机会：小团队可切入的方向
文章对比称，大公司可能投入整个季度自研内部智能体平台，而一套可用调度框架只需一个文件夹、一份yaml配置、五段简短脚本和Kimi订阅即可运行。作者看好模型新版本发布托管服务，因为每次大模型更新都会重排排行榜，拥有调度框架的团队需要有人在新版本上线当天完成替换测试。此外，面向小团队定制配置、钩子与校验器，或打包垂直行业模板，也是可探索的方向。
Q&A
什么是调度框架工程（harness engineering）？
调度框架工程是指把提示词、上下文、工具、循环、图、评估等工程整合为同一套系统的理论。调度框架是包裹在大模型外层的整套系统，包含模型可调用的工具、启动前读取的文件、允许写入的目录、输出必须通过的校验规则、触发任务的定时机制以及终止任务的判定条件。
调度框架工程和提示词工程、上下文工程等有什么关系？
提示词工程、上下文工程、循环工程、图工程、评估工程等本质上都是同一台机器上的不同零件，各自对应调度框架中的一个组件：提示词工程对应SKILL.md任务描述文件，上下文工程对应上下文组装器，工具工程对应工具声明，循环工程对应任务运行器，图工程对应记忆层，评估工程对应校验器。调度框架工程负责把这些模块整合在一起。
为什么说调度框架是唯一不随模型版本变动的部分？
底层大模型一直在迭代更新，有的版本一次更新就能在排行榜上跃升17名。而调度框架是整套系统里唯一完全属于你、不会跟着模型版本变动的部分。把模型抽象成一行配置后，模型替换后其余代码依然可用，只需修改model那一行配置即可。
如何用一份yaml配置搭建可移植的AI智能体？
把整套调度框架写进一份配置文件，核心逻辑集中在三行：model单独占一行，其余配置不依赖具体模型；permissions权限配置优先级高于tools工具列表，明确可写目录和需确认的高危操作；verify校验部分包含脚本校验和独立智能体校验。再配合钩子脚本，即可实现可移植智能体。
为什么选择Kimi K3作为调度框架的内核？
调度框架有三个核心需求：支持批量并发执行任务，Kimi K3提供智能体集群能力，最多可同时启动300个智能体；模型代码能力要足够强，能自行编写校验脚本，Kimi K3在前端代码竞技场排名第一，得分1679；底层模型能持续迭代升级，Kimi K3在7月一次更新中排行榜名次从第18名冲到第1名。
钩子函数在调度框架中起什么作用？
钩子是一段简短脚本，在模型执行动作的固定节点自动触发，不受模型决策影响，让调度框架成为一套安全防护系统。pre_tool钩子拦截写入权限外目录的操作；post_tool钩子执行格式校验并丢弃错误输出；pre_send钩子把消息放入队列等待人工确认；on_fail钩子把失败原因附加到重试请求；post_run钩子在任务结束时追加运行记录并更新知识图谱差异。
如何检验一个智能体框架的好坏？
最快的方法是只修改model那一行配置，重新跑一遍任务，即模型替换测试。凡是跑崩的地方，都是把框架逻辑错误塞进了模型侧。例如输出格式不稳定说明格式逻辑写在了提示词里；任务不会自动停止说明停止规则写在了提示词；历史修正规则丢失说明规则放在对话历史里；实体重复录入说明依靠模型自行合并；向禁止目录写入说明只靠提示词提醒。能通过测试的框架具备可移植能力。
这套调度框架夜间自动运行的流程是怎样的？
凌晨2点触发器启动，检索所有需要处理的知识节点，智能体集群并行启动，一个节点分配一个智能体。不符合数据格式的返回结果在post_tool阶段直接驳回，被驳回的节点带上失败原因重试一次。写入权限外文件夹会被pre_tool钩子阻断。校验通过的节点与关联关系存入图谱，待发送邮件停在pre_send队列等待确认。任务结束后post_run保存运行日志，满足停止条件自动终止，全程不超过45分钟。早上7点半只需读取日志做两个决策。
基于调度框架有哪些商业机会？
文章提到三个方向：面向小团队搭建专属调度框架，一次性收取四位数费用，交付适配业务流程的配置、钩子、校验器；模型新版本发布托管服务，按月收费，每次大模型更新执行替换测试帮团队迁移；垂直行业模板调度框架，打包整套文件夹和yaml配置，面向科研、招聘、合规等行业售卖。其中第二个方向被优先看好，因为每次大模型新版本发布都会重排排行榜，所有拥有调度框架的团队都需要有人在新版本上线当天完成模型替换测试。
