Flowness 工程进展：从需求到交付 · 阅读系列导读 →
Agent harness 是包在模型外面的一层运行环境和规则，让一项要持续几天、换过几次会话、经过几个 agent 之手的工作，始终知道要做什么、做到了哪里、由谁判断做完。模型负责在一次调用里想出下一步，harness 负责让这一步接得上上一步，也留得下证据。
这一章按我们做 Flowness 时碰到的问题，列出这一层要管的事，说明它与 agent framework、模型 API 的分界，再梳理中文里现有的叫法。每个论点都指向手册里讲它的那一篇，文章里的机制来自 Flowness 的源码、测试和运行记录。本章归纳的是这些文章，不代表业内对这个词的统一定义。
一次调用成功，工作不一定成立
先看我们自己遇到的一件事。2026 年 6 月 1 日，Flowness 有一项自开发任务：把上下文胶囊接进生产会话。胶囊在一次运行开始时组织任务材料和约束；提交门在运行结束时按胶囊检查改动有没有超出范围。两个部件都已经写好，测试也能通过，但生产入口没有调用汇编，提交信封里填的是一个占位引用。提交门回查不到这一轮的真实胶囊，范围检查因为缺少基准被跳过。
于是提交顺利通过，范围检查却没有执行。调用过提交门，与提交门真正做了语义检查，是两件事。这个问题出在模型之外：谁在什么时候把什么材料交给了谁，结果又凭什么被接受。过程见《把上下文接到任务上：一次 Flowness 自开发实录》。长时间运行的 agent 工作里有很多这样的缝隙，harness 就是管这些缝隙的那一层。
Agent Harness 管哪几件事
下面六件事在 Flowness 里各有对应的机制。分类是我们为讲清楚做的整理，不同系统的切法会不一样。
任务与交接
一项工作交给下一位时，最容易丢的是代码背后的决定：这次要解决什么问题，哪些约定已经确定，执行者可以改到哪里，由谁判断做完。Flowness 把交接做成了固定的链条：需求简报确认范围和完成条件，任务包把上游决定压成一个可接手的范围，上下文胶囊说明本次行动依据什么开始，提交信封把执行结果作为候选交回。每一环的设计见《从需求到验收：Flowness 怎样把一项工作串起来》。
交接还要分清三种状态：任务在推进，会话可能已经换手，成果可能还在验收。会话退出不等于任务完成，代码合入也不等于验收合格。《长任务怎样交接、暂停与验收》用一个假设的、跨几天的权限改造例子，加上 2026 年 9 月 15 日一次实际暂停的记录，讲了接班时核对什么、暂停时分哪几层。
上下文
每次行动都要准备材料：当前要做什么，用户有什么约束，前一步留下了什么，有哪些反例不能忽略。全塞进提示词，长日志会挤掉要读的内容；先做摘要，摘要的取舍又会替下一位决定他能看到什么。Flowness 的上下文工作集按角色（执行、修复、审阅、规划）列出必读材料，在阅读预算内排序，并记录哪些是原文交付、哪些只是审计投影，见《上下文工作集》。
历史越积越长以后，还要能快速找到与某个任务有关的记录。《增量事件索引》讲的是新事件只补进索引、查询命中后才展开正文，让完整保存历史与每次只读需要的部分同时成立。
权限与边界
拿到任务的执行权限，不等于获得改写设计约定的权限。执行者发现接口约定不成立，应当报告这个前提问题，不在执行途中悄悄改。Flowness 用任务包里的读写范围和提交门的范围检查落实这一点，原则见《从需求到验收》；前面的自开发实录讲的是范围检查在生产入口被跳过、后来接通的过程。
事件与验收
agent 说“完成了”，系统随后可能停止重试、解除依赖、放行下游。所以这句话要变成可核对的事件：谁完成了哪次运行，依据是什么。我们修正过一条写入路径：完成声明可以藏在通用事件载荷里，借允许直接写入的路径进入账本，再被消费者当成正式完成事实。修正办法见《完成事实的入口：类型化事件与共享写入边界》。
验收这一端同样要查证据。一次测试退出码为零、通过数也够，登记册里一条必须执行的测试却已经消失，同一文件里的其他测试补足了通过数。《从问题登记册到合并关口》复盘了这个反例，以及随后的逐目标审计和关口负对照。需求这一端也有对应的判断：《访谈停止判定》讲怎样判断需求信息已经足够进入设计。
调度与成本
任务多了，要决定先做哪个、同时做几个、失败几次就停。《DAG 任务调度》讲先检查前置工作，再优先推进最长依赖链；《预测配额调度》讲按剩余额度、消耗速度和重置时间收紧新任务准入，代码默认以影子模式运行；《有界重派》给自动恢复一份独立的次数预算，耗尽后持久记录停止状态；《机器告警去重》把复发的问题归入仍未解决的同一条告警。
恢复
长时间运行意味着进程会退出，连接会中断，旧执行者会在被取代之后突然回来。《游标最后推进》从扫描器在读取和计数之间退出的例子，推导出游标、计数和字节水位的写入顺序，使信号可以重放而不重复计数。《世代号写入隔离》处理另一种情形：租约到期后新执行者接手，存储端再核对世代号，拒绝旧执行者迟到的写入。
Agent Harness 与 agent framework、模型 API 的边界
三者经常被放在一起比较，下表只按各自主要承担的事划分。
| 模型 API | agent framework | agent harness | |
|---|---|---|---|
| 主要提供 | 一次调用：输入进去，输出回来 | 搭建 agent 的构件，如调用循环、工具接口、编排原语 | 让一项工作跨越多次调用、多个会话和多个执行者仍然成立的运行规则 |
| 状态 | 调用之间默认不保留 | 由使用者决定怎样保存 | 任务、事件、依据和交接物是它要管理的对象 |
| 回答的问题 | 下一步说什么 | 怎样把 agent 搭起来 | 这项工作做到哪里了，凭什么算做完，出了错怎样接着做 |
这个划分有重叠：framework 也可能带检查点、重试、权限这些 harness 层的功能，harness 内部也要调用模型 API，用某种 agent 循环。中文社区已有不少文章讨论这组关系，例如菜鸟教程的《Harness Engineering（驾驭工程）》和 Datawhale 的《从 Agent Framework 到 Agent Harness》，可以对照看不同作者怎样划线。我们的切法来自“工作要持续好几天”这个具体场景。
Harness 的中文叫法
harness 的字面意思是马具、挽具，也指把线路固定整齐的线束。用在 agent 上，中文里目前能看到这几种处理：
- 不翻译，直接写 Agent Harness 或“Harness 工程”。不少中文文章和问答直接用 Harness Engineering 或 Harness 工程，例如知乎上的问题《什么是Harness工程？》。
- 驾驭工程。见百度百科“驾驭工程（AI工程化范式）”词条、菜鸟教程。
- 挽具工程。见36氪《聊聊Harness时代AI-First的组织架构》、掘金上的一篇文章。
- 约束系统工程。见技术栈网站上的这篇和这篇。
这几种叫法都有人在用，还没有哪一种成为通行译法。手册里直接用 harness 这个英文词，不预先替读者选定译法。
Flowness 是我们的 agent harness
Flowness 是 ToWow 用来组织多个 AI agent 持续协作的 agent harness，管理任务、上下文、工具调用和工作记录。上面引用的文章，都是做它的过程中遇到的真实问题和修正。《从第一个项目，长出企业自己的 Flowness 工作方法》讲企业怎样从一个真实项目开始积累自己的方法。