假设让 AI 做一份项目周报：它写得很顺，但用的是上周的表格；你提醒它更新数据，它又漏掉了前面确认过的统计口径。最后还是得打开文件，一项项核对。

这类问题，换一个更强的模型未必就能解决。模型要先拿到对的材料，系统要记住已经确认的要求，还得有人或程序检查结果。中间少了一环，文字再流畅，也交不了差。

办公 Agent 背后这套负责组织材料、调用工具、保存进度和检查结果的系统，通常被称为 Harness。理解它不用先学一堆术语。选产品时，把下面三个问题问清楚，就能看出不少差别。

资料拿得对，工具接得上吗？

做周报需要的材料，可能散在表格、会议纪要和项目系统里。用户不想把它们搬来搬去，Agent 就得能访问相应位置，并把本次任务真正需要的信息交给模型。

这也是连接器值得看的原因。能接你正在用的办公系统，往往比菜单里有多少个陌生服务更重要。还要分清：它只能查资料，还是能修改文件？权限由谁授予，哪些操作需要确认？

材料接进来之后，也不能一股脑全塞给模型。过期版本、重复内容、无关对话，都可能干扰判断。Harness 要处理的，是这一步决策究竟该看到什么，以及哪些约定必须留下。

Skill 则可以把常用做法固定下来，比如周报的栏目、统计口径和检查步骤。下次不用重新交代，但这些规则仍要有人维护。公司的模板换了，旧技能也可能继续输出一份格式漂亮、口径过时的报告。

任务做一半，能接着往下走吗？

短任务容易掩盖问题。等到一项工作要经历搜集、核对、分析、制图，再写成文档，就会遇到工具报错、资料缺失，或者对话太长，需要整理上下文。

这时，保存了哪些文件、哪些步骤已经完成、哪里还没验证，都应该有记录。否则重新开始一轮对话，模型可能把做过的事再做一遍，也可能误以为任务已经结束。

多 Agent 协作同样绕不开这些细节。让一个负责查资料、另一个负责写报告，听起来很合理。但资料还没查完，报告就开始写，分工反而制造了新的返工。能并行的工作有哪些，后一步必须等什么，系统需要安排清楚。

验收也得具体。文件能打开，未必代表表格算对了；页面生成成功，未必代表按钮能用。任务做到哪一步可以交付，要靠结果检查，不能只凭模型说一句“已完成”。

这次踩过的坑，下次还会踩吗？

一项任务跑完，除了最终文档，还留下了另一类有用的东西：执行记录。模型调用过什么工具，在哪一步失败，用户改了什么，最后怎样才通过检查，都能帮助开发者找到问题。

比如，若多次失败都发生在读取旧版文件这一步，就该检查文件选择规则；若用户总在修改同一个统计口径，就该检查任务说明和技能。这比只看最终答案好不好，更容易找到需要修的地方。

因此，Harness 的执行过程可以提供新的数据，用来改进规则、设计评测，或在符合数据使用要求的前提下用于训练。但有日志不等于会学习。记录需要筛选，反馈需要判断，改完还要验证是否真的少犯错。

这也解释了办公入口和企业系统为什么重要。离实际工作越近，越有机会发现模型在哪些步骤帮上忙、又在哪些地方让人返工。不过，能积累这些记录，也要把权限和数据边界管好。

比较办公 Agent 时，可以拿同一份脱敏材料，交给候选产品做同一个任务。除了看成品，再看自己中途补了多少材料、纠正了几次、收尾用了多久。模型型号和订阅价格都值得比较，而这些来回修改的时间，才是账单上没有写出来的成本。