搭建代理运行框架，成本藏在任务生命周期

给每个 AI 任务启动一个容器，并不等于造好了 Agent 的运行底座。作者讨论的 Agentic Harness，是围绕 Agent 建立的一套执行与管理机制：任务离开终端后，谁接管生命周期，谁决定权限，谁验证结果，又由谁保留证据。

他的结论很明确：容器这堵墙相对便宜，真正的成本在墙外。对准备把 AI 编程从人工盯守推进到后台执行的团队，这篇文章提供了一份实用的设计检查表，但没有给出完整实现或性能数据。

容器管运行位置，角色管动作边界

作者估计，为每个任务启动一个容器，花一个下午就能做出来。这是他的经验判断，文章没有交代技术栈或测量过程。

麻烦出现在任务开始独立运行之后。既然用户可以合上电脑离开，任务就不能继续依附于本机终端里的进程。它需要一条持久化记录，还需要有人负责启动、观察结束状态、保存产物。原来由人在终端前承担的职责，现在都要进入系统。

容器也只解决了一半隔离问题。它决定任务在哪里运行，却没有回答执行者能读什么、能改什么、能调用哪些动作。作者建议用角色描述这些边界，包括使用哪个模型、读取范围和允许的操作列表。

例如，协调任务的角色不持有编辑权限，负责交付的角色不能自行声明新工作。作者反对把决定做什么、实际执行、宣布完成全部交给同一个 Agent，因为外面的容器再严密，内部也没有职责边界。

权限还必须适应无人值守。交互式工具遇到敏感操作可以等人确认，后台任务这样做就会一直挂着。预授权太宽，会削弱隔离；太窄，又可能让任务停止，甚至表面继续运行却没有产物。

角色的价值在于让授权可审查：针对一类工作列一次权限，其他人可以逐项提出异议。但作者也承认，这仍然是预先做出的判断，不能保证每次都够用。

显示完成之前，要分别检查状态和产物

模型擅长输出描述，所以没有约束的 Harness 很容易收到一句「已经更新处理函数，应该能正常工作」。这句话不能直接作为任务结果，因为最后仍然需要人来判断它到底完成了没有。

作者提出，先列出任务允许出现的结束状态，再严格匹配。没有命中任何状态的输出应当判为失败；「放弃」也必须是合法状态，并附带原因。

任务结束和目标达成，必须分别验证。

作者讲过一个亲眼见到的案例：流水线执行了所有指定步骤，报告成功，最后却什么都没有交付。原因是它使用的身份无权创建目标对象。过程中没有异常，产物也没有出现。

这说明即使结束状态规范化了，仍然要检查真实结果。系统需要回答两道题：这次执行怎样结束，以及要求的东西是否已经存在。

权限设计也依赖这套结果机制。如果授权不足，系统至少要把拒绝操作和原因明确反馈出来。否则，缩小权限只是把风险变成了更难发现的空结果。

文章没有规定状态字段、返回协议或验收接口，因此这里可以借鉴的是设计约束，不能当成现成规范直接接入。

容器可以销毁，执行证据必须留下

作者区分了两类信息：Agent 对自己工作的陈述，以及它实际执行过的证据。

前者可能是一段漂亮的完成总结；后者包括命令、输出、代码差异和权限拒绝记录。排查问题时，需要的是后者，因为它允许别人复核过程，甚至推翻 Agent 的判断。

这与容器的短生命周期形成了冲突。隔离环境通常希望任务结束就销毁，但里面可供检查的信息不能随之消失。因此，Harness 还得承担证据导出的职责，在环境清理前，把有价值的执行记录保存到外部。

对 AI 编程任务来说，只保存最终回复远远不够。补丁改了哪里，检查命令返回了什么，哪一步被权限挡住，都可能决定这次结果能否被接受。

文章没有展开记录格式、存储方式、保留周期，也没有给出证据保存带来的开销。这部分讲清了为什么必须做，距离工程方案还有一段路。

多任务并发后，为什么没报错也要报警

作者把并发运行需要补上的机制分成三类。

第一类是准入控制（admission）。模型配额、容器、机器和预算都有上限，系统必须决定哪些任务现在可以启动。把队列里的工作全部同时放出去，很可能让所有任务一起争抢资源。

第二类是任务认领（claim）。执行前先声明某项工作由谁处理，而且其他执行者必须看得到。任务结束后释放认领；执行者消失时，认领还需要自动过期。否则，要么重复开工产生冲突，要么工作一直被占住。

第三类是守护检查（guard checks）。系统不能只监听报错，还要主动检查工作是否继续流动。

作者举的检查非常直接：队列里有任务等待，却没有任务正在运行。这个状态可能不触发任何异常，但系统已经停住了。定时执行一次查询并报警，就是一个成本很低的起点。

并发也会放大判断问题。只有一个任务时，人可以翻记录、看产物；多个任务无人值守时，人工复核容易跟不上，Harness 自身也可能成为瓶颈。

我的判断

这篇文章最有价值的地方，是把 Agent 的可靠性拆成了可以落实的责任：任务要留记录，权限要列清单，结果要验收，停滞要被发现。这些责任不会因为模型更强就自动消失。

不过，「角色是放置授权最便宜的位置」属于作者的经验之谈。文章没有提供与逐次授权、按资源授权等做法的对照数据，也没有证明某种角色划分适合所有团队。实际采用时，还得看任务变化频率和权限管理成本。

作者也没有解决更难的问题：系统是否理解了人的真实意图。他认为窄范围、小任务相对容易处理，范围扩大后，质量会下降，任务会偏离目标；下一步想尝试类似敏捷开发的节奏和工作评审。这是后续设想，还不是验证过的结论。

因此，检查产物存在只能证明交付物没有缺席，不能证明它解决了正确的问题。相较于人工盯着终端，Harness 承接了更多运行责任；至于需求理解和质量判断，仍需要明确的验收依据。

能拿来做什么

• 给后台 AI 编程任务建立持久化记录，写清允许的结束状态，并让权限不足、主动放弃等情况带着原因返回，避免任务只留下含糊的完成回复。
• 为修改代码的任务单独设置产物检查。例如要求交付补丁时，核对补丁是否存在、是否包含目标修改，并保存对应检查输出。
• 在清理临时容器前导出命令、输出、代码差异和拒绝记录，让任务结束后仍然能够复核执行过程。
• 如果已经运行多个 Agent，就检查任务认领是否会释放或过期，并增加「有任务等待但没有任务运行」的定时告警，及时发现静默停滞。