一旦框架拥有了工具、上下文、权限、内存以及每次运行的验证，K3 就不再仅仅是一个聊天机器人。其运行流程为：一个目标 → Kimi K3 → 工具 → 循环 → 内存图 → 验证器 → 人工审批。
有趣的是，模型变得可替换。K3 可以在一次更新中提升 17 位排行榜排名，而其余工作流程保持不变，集群扇出可达 300 个代理。同一个框架可以运行研究、编码和多步骤作业，而无需每次都重新构建编排。
这才是更大的转变：真正有价值的层不再是提示层，而是当模型发生变化时仍能继续运行的系统。
提示词工程、上下文工程、循环工程与图工程，本质上都是同一台机器上的不同零件。而调度框架（harness），就是承载所有零件、让它们协同运转的载体。
搭建AI应用的过程里，陆续诞生了一堆细分工种。最早是提示词工程，那个阶段大家的核心工作，就是写对一句话。
随后出现了上下文工程。人们很快意识到，一句话本身的重要性，远不如加载给模型的全部背景信息。今年夏天，循环工程开始流行；没过几周，图工程也火了。
现在一个新名词正在传播：调度框架工程（harness engineering）。它是第一个能把前面所有概念全部解释清楚的理论。
调度框架，就是包裹在大模型外层的整套系统：模型可以调用的工具、每次启动前读取的文件、允许写入的目录、输出结果必须通过的校验规则、触发任务的定时机制，以及终止任务的判定条件。
前面提到的各类工程，其实都只是这个框架里独立拆分出来的组件，还各自拥有了名字。
我关注这个方向，是出于很现实的考量：底层大模型一直在迭代更新，有的版本一次更新就能在排行榜上跃升17名。而调度框架，是整套系统里唯一完全属于你、不会跟着模型版本变动的部分。
一、七大工程，同属一台机器
提示词工程，要解决的问题是我到底要向模型提出什么任务，在调度框架里对应的位置是SKILL.md这份优先加载的任务描述文件。
- 上下文工程，回答的是模型在每一步能看到哪些信息，对应的是上下文组装器，里面包含约束条件、数据结构、检索拿到的页面内容。
- 工具工程，定义模型能操作什么资源、输入输出是什么格式，对应带类型定义输入输出的工具声明。
- 循环工程，确定任务何时启动、何时结束，对应的是任务运行器，包含触发器、终止条件、资源配额。
- 图工程，负责模型要记住什么信息、信息之间如何关联，对应记忆层，包含节点、带类型的边、别名映射。
- 评估工程，用来判断什么样的结果需要驳回，对应的是校验器，独立于智能体之外，不受智能体本身控制。
- 调度框架工程，目标是把上面所有模块整合在一起，对应的是整体框架、权限配置以及钩子函数。
从上往下读这一段描述，能看到AI工程能力一路演进的历史。反过来从下往上读，则是一套完整的系统架构：调度框架工程，就是决定其余六大模块放在哪里，避免所有逻辑都被塞进提示词里。
这一点至关重要。提示词是最方便塞逻辑的地方，于是所有东西都往里面堆：输出格式、停止规则、上周修正的错误清单、智能体绝对不能触碰的资源列表。这套写法，在你当初调试的模型上运行完美；可一旦换成新模型，同一段文字就会被理解成完全不同的含义。
二、调度框架的内部结构
我养成了一个很实用的习惯：把整套调度框架写进一份配置文件，任何关键逻辑都不隐性埋在代码里。
text
# harness.yaml
model: kimi-k3 # 仅一行配置，其余代码模型替换后依然可用
tools: [browser, fs, shell, search]
permissions:
write: [./10-returns, ./20-graph, ./40-runs]
ask_first: [send, publish, pay, delete]
context:
always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]
per_agent: return_schema
runner:
trigger: cron "0 2 * * *" # 凌晨2点定时自动运行
stop: 40 verified nodes OR 3 passes with nothing new
budget: { agents: 300, minutes: 45, retries: 2 }
memory:
graph: ./20-graph
aliases: ./aliases.csv
verify:
- script: checks/schema.py
- agent: reviewer, fresh context
hooks:
pre_tool: hooks/pre_tool.sh
post_run: append 40-runs/
这份配置里，核心逻辑只集中在三行。
model单独占一行是刻意设计的。其余所有配置，都做到不依赖具体模型。这就是整套系统可移植性的核心。
permissions权限配置，优先级甚至高于tools工具列表。明确写明智能体可以修改哪些目录、哪些高危操作必须先申请确认。这就是区分“可以放心后台整夜跑”和“必须人盯着”两套智能体系统的分水岭。
verify校验部分写了两项，有明确原因。脚本校验成本极低，可以拦截所有格式类错误。第二个校验器是独立智能体，它看不到第一轮智能体的执行过程。因为如果让智能体自己给自己的结果打分，总能找到理由放行错误输出。
在本地文件系统里，整套调度框架就是一个文件夹，上面提到的每一类工程，都在文件夹内拥有专属存放位置。
三、为什么我选择Kimi K3作为框架内核
调度框架第一个核心需求，是系统能够支持批量并发执行任务。Kimi K3提供的能力是智能体集群，针对同一个问题最多可以同时启动300个智能体，不需要开发者手动编写复杂编排器。
调度框架第二个需求，模型代码能力要足够强，可以自行编写校验脚本。Kimi K3在前端代码竞技场排名第一，得分1679，超过Fable 5的1631分、GPT-5.6 Sol的1618分，7个评测维度拿下6项第一。
调度框架第三个需求，底层模型能够持续迭代升级。Kimi K3在7月的一次版本更新中，排行榜名次直接从第18名冲到第1名。
第一点的价值比看上去更大。几乎所有自制调度框架，写到后面都会手写一套编排器，而编排器往往是整套系统最脆弱的部分。Kimi自带智能体集群能力，并发只需要在配置里写agents:300配额，调度框架只需要接收返回结果即可。
第二点同样关键。调度框架里大量脚本其实由模型自己生成：钩子脚本、格式校验程序、读取运行日志的简易看板。前端代码领域领先的模型，写这类代码一次性通过的概率高很多。
第三点，就是调度框架工程价值最直观的数据证明。当模型一夜之间排行榜跃升17位，只要框架做好了隔离，当天就能用上新版本——只需要修改model那一行配置。
四、钩子函数：调度框架的自动防护反射
钩子就是一段简短脚本，在模型执行动作的固定节点自动触发，不受模型决策影响。钩子让调度框架不再只是文件夹结构，而是一套安全防护系统。
pre_tool钩子会在调用任意工具之前触发，作用是拦截写入权限列表以外目录的操作。
post_tool钩子在工具返回结果之后触发，立刻执行格式校验，直接丢弃格式错误输出。
pre_send钩子在任何信息对外发送之前触发，把消息放入队列，等待人工确认才能发出。
on_fail钩子在结果校验失败之后触发，把失败原因附加到重试请求里。
post_run钩子在触发停止条件、任务结束的时候触发，追加本次运行记录，更新知识图谱差异。
pre_tool前置钩子，核心代码短短5行：
text
# hooks/pre_tool.sh
case "$TARGET" in
./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;
*) echo "blocked: $TARGET is outside the write list"; exit 1 ;;
esac
单独一个on_fail失败钩子，就能改变循环任务的成本。重试的时候带上上次失败原因，这才是有效的修正。如果不带失败原因，循环会反复踩同一个坑，白白消耗资源。
五、整套系统夜间运行流程
把所有模块组合完毕，调度框架就像一个遵守规则的夜班运维。凌晨2点触发器启动，检索所有需要处理的知识节点。智能体集群并行启动，一个节点分配一个智能体。
不符合数据格式的返回结果，会在post_tool阶段直接驳回，不会写入图谱；被驳回的节点会带上失败原因重试一次。一旦智能体尝试写入权限外文件夹，pre_tool钩子直接阻断，无需人工介入。
校验通过的节点与关联关系存入20-graph图谱。待发送邮件会停在pre_send队列等待确认。任务结束后post_run保存运行日志，当满足停止条件就自动终止，全程不会超过配置里45分钟的资源上限。
早上7点半，你只需要读取一份日志文件，做两个决策。这就是用循环工程、图工程搭建这套系统之后，每天只需要付出的人力成本。调度框架的核心意义就在这里：能自动完成的全部自动跑，少数需要人判断的事项，统一汇总在一处等待处理。
六、模型替换测试：检验框架好坏的最简办法
检验智能体系统质量最快的方法：只修改model那一行配置，重新跑一遍任务。凡是跑崩的地方，都是把框架逻辑错误塞进了模型侧。
更换模型之后如果出现输出格式不稳定的问题，说明相关逻辑原本错误写在了提示词里，写着“永远返回JSON”，正确做法是定义结果数据结构，搭配脚本强制校验，不合格直接丢弃。
更换模型后任务不会自动停止，代表之前把停止规则写在了提示词，类似“一直运行直到结果完善”，正确方式是设置基于数量的停止判定条件。
更换模型后历史修正规则丢失，说明规则放在对话历史里面，正确做法是单独放到CONSTRAINTS.md，每次任务启动自动加载。
更换模型后同一个实体多次重复录入，代表之前依靠模型自行判断去合并实体，正确方案是维护aliases.csv别名表，合并实体之前自动校验。
更换模型后智能体向禁止目录写入文件，代表之前只在提示词写一句提醒，正确方案是配置权限清单，搭配pre_tool钩子拦截非法写入。
可以顺利通过模型替换测试的调度框架，具备可移植能力。而可移植，才是这套系统能产生商业价值的根本。
成本与收益
很多公司会投入整个季度去自研内部智能体平台。但一套可用的调度框架，只需要一个文件夹、一份yaml配置、5段简短脚本，搭配Kimi订阅即可运行。这中间巨大的落差，就是当下的机会。
面向小团队搭建专属调度框架这个方向，可以一次性收取四位数费用，交付适配业务流程的配置、钩子、校验器；做这件事的前置条件是你手上已经拥有一套可以定时运行的调度框架原型。
模型新版本发布托管服务，可以按月收费，每次大模型更新就执行替换测试，帮团队迁移到新模型；这个业务需要客户的运行日志统一存入40-runs目录。
垂直行业模板调度框架，可以打包整套文件夹和yaml配置，面向科研、招聘、合规这类行业售卖；前提是同一套框架已经在两个不同场景验证稳定。
第二个方向，是我优先看好的赛道。每次大模型新版本发布都会重排排行榜。仅K3这一次更新，名次就提升了17位。所有拥有调度框架的团队，都需要有人在新版本上线当天，完成模型替换测试。
一句话总结
提示词、上下文、工具、循环、图、评估工程，全部都是同一套系统里的组件。调度框架工程，就是规划好每一个组件应该放在哪里。
把模型抽象成一行配置，权限优先级高于工具，校验器独立在智能体之外。之后哪怕大模型排行榜名次大幅变动，你只需要改一行配置，不用重构整套系统。
网友锐评
循环 vs 流程图：2026 年能让你升职的那个关键区别
随便问十个用 Claude 的工程师：你们用的是哪套？八个答不上来。差距就在这儿。
> 循环：你定个大方向，智能体自己去找路。最适合还没人知道路该怎么走的时候。
> 流程图：你把路线画好，智能体一个节点一个节点填。最适合每天都是同一套活儿的时候。
循环很灵活，但不好测。流程图测起来干净，但前提是你得先有那张图。
要是你把公司的“大脑”——工单、制度、文档这些——扔一边不管，智能体每次跑都得重新学一遍你的业务。
乱糟糟的活儿，用 Fable 5。每天固定重复的流程图，用 Opus 4.8——前沿档，更便宜，能跑一整天。
一个循环一旦不再让你意外，就赶紧把它固化成流程图。
你在规划会上说一次这话，你就不再是干工单的人了，你是在设计系统。