GOSIM深圳2026大会10月17日的议程，把《State of Harness Engineering》和《Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses》排进智能体主题论坛。两个题目把注意力从“哪一个模型最强”拉回执行系统：模型得到什么上下文、能调用什么工具、出错后怎么恢复，决定了交付给用户的实际结果。议程能证实这些议题受到讨论；具体演讲内容、实验收益与产品发布，仍须由讲者材料或独立测试支持。
我的判断是：**Harness的价值不是让代理多跑几轮，而是让每一轮的状态可解释、出错可恢复，最终结果可验证。**同一模型在一次性的问答测试里能写出漂亮代码，换到持续运行的仓库里，却会遇到权限不足、依赖失败、版本漂移与需求含糊。它可能给出一段笃定的完成报告，仓库里的测试仍然失败。工程团队要测的是这两者之间的距离。
先分清两种Harness
Anthropic的智能体评测文章区分了agent harness与evaluation harness。前者负责让模型行动：处理输入、组织工具调用并返回结果；后者负责安排测试任务、记录运行轨迹、给出评分与汇总。一个生产代理即使有调度器、工具适配器和内存，也不会因为能运行就自动具备合格的评价体系。相反，离线评测框架可以把同一批任务送给不同版本的模型与执行框架，找出改动究竟带来了什么。
这个区分对预算很有帮助。采购一个带精美监控面板的代理平台，不等于已经建立业务验收。以代码代理为例，结果至少要落在一个可检验的仓库状态：目标测试通过、旧测试未退化、修改限制得到遵守、变更有人工可读的差异。代理说“已修复”，只能算一条待验证的陈述。Anthropic在评测说明里举的航班例子尤其直观：终局数据库里有没有预订，才是结果；文字里写了“预订成功”没有用。
一个任务在生产系统里的路径可拆成：接收请求与上下文、制定计划、调用工具、读取环境反馈、写入变更、运行校验、报告状态。Harness需要为每一步规定超时、权限、预算与重试行为。把终止条件交给模型自己判断，代理容易在工具故障时不断重试；把所有错误一律视为“再试一次”，又可能重复发出副作用操作。对于读取型检索，重试通常成本可控；对于删文件、发邮件或创建支付订单，恢复策略必须先检查上一次动作的实际状态。
可观测，不是把所有对话存进数据库
OpenTelemetry的可观测性入门把遥测数据分成trace、metric和log，并把可靠性定义为服务是否完成用户期待的行为。一个服务可以一直在线，用户的请求却没有得到正确结果。智能体尤其容易出现这种“接口返回成功、任务实际失败”的情况。因此第一条跨工具的追踪，应围绕一次用户任务生成关联ID，把模型调用、检索、终端执行、文件修改和校验串成一条可查询的执行链。
追踪事件不必存下全部提示词和原文。对每次工具调用记录任务ID、操作类型、目标资源的脱敏标识、开始与结束时间、结果码、重试次数、策略拒绝原因；对模型调用记录版本、输入输出Token、延迟与预算。敏感文件内容应按最小留存原则处理，可以保留散列和引用指针供授权排查，避免为了“可观测”建出一套新的数据泄露源。告警也要有节制：单次工具429适合重试，连续的授权拒绝或预算耗尽则应停止任务并通知负责人。
仅有调用链，还无法判断答案是否好。Anthropic的评测文章建议把任务、尝试、评分器、轨迹和最终环境状态分开记录；多次尝试是为了观察随机性，不能只挑一次漂亮的样例。一个编码任务可由单元测试和静态检查判定功能，由规则检查它是否修改了禁止目录，再抽样让开发者审阅可维护性。把这些分数压成“成功率97%”之前，必须先写明分母：是模型回合、工具调用、任务尝试，还是最终可合并的拉取请求？换一套分母，数字会变样。
固定任务集里，故意放进难看的故障
团队可以从自己最近一个月真实工单抽样，先脱敏，再按任务类型建一个小而稳定的回归集。不要只选描述清楚、依赖齐备、答案唯一的任务。放入几种常见麻烦：依赖安装临时失败、测试间歇失败、已有未提交改动、接口权限不足、工具返回空结果、上下文长到需要检索。每个任务先写清终局条件和禁止动作，再冻结模型版本、温度、工具版本、仓库快照与预算，让对比有意义。这里给的是可复现方法，不是假称已经有GOSIM现场公布的行业统一基准。
报表至少分四栏。第一栏是终局：真正满足用户需求的任务占比，以及错误修改和安全违规次数。第二栏是过程：不必要的工具调用、无效循环、人工接管次数。第三栏是资源：单任务Token、外部接口开销、尾部延迟。第四栏是恢复：超时、重试、回滚与重新接续的结果。如果只看通过率，增加十倍推理成本的版本会显得很好；如果只看成本，一个常把任务做错的版本又会显得便宜。把约束条件写进决策表，选型才有业务意义。
Anthropic早先的《Building effective agents》建议从简单可组合的方案开始，只有在收益可以测量时再加复杂度，并提醒抽象过厚的框架可能遮蔽真实的提示和响应。对多数企业，第一版Harness未必需要多代理辩论：一个明确的工具清单、一个状态机、可暂停的高风险节点、一个独立的验收器，已经能解决大量“演示可以，生产失控”的问题。需要并行子代理时，先给每个子任务限定可访问的目录和预算，然后在父任务汇总时校验冲突与重复工作。
可观测性驱动改进，首先要能回放
假设版本A完成了一个仓库迁移，版本B加入自动重试后在同一任务上失败。没有轨迹，只能猜是模型退步、外部依赖改变，还是重试把工作树覆盖了。有了事件链，可以找到第一次偏离：比如工具返回了“权限不足”，Harness却把它裁成一段普通文本继续送入模型。修复点可能是适配器把错误结构化，而不是换模型。下一次重放同一任务，比较两版的终局与错误轨迹；若修好一个故障同时带来大量额外调用，也应当看到成本账单。
回放环境也会骗人。今天的依赖包与明天的不一样，外部API的返回结果更可能变化。测试单上要写明仓库初始提交、工具容器镜像和数据集版本；真实生产令牌别带进离线评测。无法完整重演的外部交易，留下脱敏的请求与响应元数据，另外用模拟服务核对决策流程。工程师需要的是定位版本改动，而不是假装外部世界能按下暂停键。
GitHub对Copilot cloud agent的产品说明也提供了现实边界：它在临时云端开发环境里读文件、改代码、运行测试，产生会话日志供人查看；文档明确提醒日志不能替代人工审阅，输出仍可能含安全漏洞。企业采用任何编码代理都应有类似的提交前门禁。一个操作清楚、日志完整的代理，仍可能按照错误需求把系统改坏；验收必须回到业务规则、测试覆盖和代码审查。
Harness工程最终会落在一串不太浪漫的问题上：任务是否真的完成，失败时钱花在哪里，谁能解释一笔越权调用，下一版是否把旧毛病带回来。GOSIM议程让这些问题拥有了独立讨论的位置。企业要拿到真实可靠性，则得从自己的任务集、可查的轨迹和明确的终局条件开始，一次版本更新一次版本更新地验收。
参考资料
- GOSIM Shenzhen 2026, Schedule（会议日2026-10-17）：相关论坛与Harness议题的官方议程。
- Anthropic, “Demystifying evals for AI agents”：评测Harness、代理Harness、轨迹、最终状态与评分方法。
- Anthropic, “Building effective agents”：代理架构、工具设计、环境反馈、复杂度与测试原则；页面提示旧文部分工具背景已更新。
- OpenTelemetry, “Observability primer”：追踪、指标、日志及面向用户行为的可靠性定义。
- GitHub Docs, “GitHub Copilot on GitHub.com”：云端代理工作环境、会话日志与人工审核限制。
两幅配图为工程概念示意，图中流程不代表大会现场展示的具体产品。