Agent Harness确定性调度：从概念到Python实现

在 agent 工程实践中harness 这个词这几年被反复提起。社区里的 codex harness、deepseek harness 一类工具表面看是给模型套了一层可执行外壳实际上解决的是一个更本质的问题当模型输出无法保证稳定绕过模型、由外部控制层来决定任务何时开始、哪些任务可以并发、失败后如何重试这层能力到底能不能做成确定性的调度器和任务编排器答案是能但有前提。真正的确定性不在模型推理层而在 harness 的执行层。你可以让模型自由生成任务图但任务图一旦被校验和冻结接下来的执行顺序、并发边界、失败传播、重试策略都应该由调度器按照固定规则完成。这篇文章会围绕这个判断展开先说清楚 harness 在 agent 系统里的位置再解释“确定性”为什么必须分层实现然后用一个最小 Python 实现演示如何把 DAG 调度、状态机和任务编排装进 harness最后给出验证方法、常见坑和生产环境落地建议。1. 先理解 harness 在 agent 系统里到底管什么1.1 从提示词包装到执行控制层早期把 LLM 接进业务系统最常见的做法是把提示词写进一个函数调用模型后拿到字符串再解析。这种做法只能叫提示词包装因为模型输出之后后续步骤仍然靠人肉处理谁调用工具、谁检查结果、谁决定重试都没有固定的控制结构。harness 不同。它是包在模型推理循环外面的执行控制层负责管理上下文、工具调用、权限策略、日志跟踪和失败处理。所谓 agent harness就是把一个模型的“思考-行动-观察”循环变成一套可以被外部代码控制的流程。harness 工程的核心价值不是让模型更聪明而是让模型产生的动作更安全、更可追溯、更可复现。在 CLI 编程 agent 领域harness 的职责更具体允许模型读取哪些文件、执行哪些命令需要审批、修改代码后是否自动运行测试、每一步的输入输出如何归档。这里的共同点是harness 把模型的自由输出约束成一组可观察、可批准、可重试、可回滚的操作序列。1.2 为什么调度器会变成 harness 的核心矛盾单轮问答场景不需要调度器。模型输入一句话输出一句话流程就结束了。但 harness 一旦进入多步骤任务问题立刻变复杂先抓取代码再分析变更然后请求审批最后归档结果。这些步骤之间存在依赖关系而且依赖关系不一定来自模型本身还可能来自外部系统约束。这里有一个天然矛盾。从功能角度harness 需要模型参与规划因为只有模型知道“先看代码再总结影响”这样的语义从稳定性角度harness 又希望执行顺序和结果可预测否则无法做测试、无法审计、无法在失败后复现。于是调度器进入了 harness 的核心模型负责生成任务的语义调度器负责执行任务的纪律。调度器决定哪些节点已经就绪、哪些节点可以并发、失败节点如何影响下游、重试间隔是多少。这也是“harness 和 agent 区别”最容易讲清楚的地方agent 是模型侧的规划与行动能力harness 是工程侧的执行与控制能力。2. 不要把“确定性”理解成一个整体开关2.1 先区分模型推理层和执行编排层讨论“harness 能不能有真正确定性的调度器”之前要先把系统拆成两层。第一层是推理规划层。模型根据用户目标生成候选步骤这一步天然是非确定性的。即使温度