如何体验不同产品的Harness的优缺点，实际体验的时候重点观察Harness背后哪些行为

回复 群友 716： 最有效的方法不是分别随便聊几句，而是拿同一个真实任务，观察它们“顺利时怎么推进，出问题时怎么收场”。 比如：给一个你熟悉的小项目加搜索功能，要求兼容旧接口、补测试、不修改某个目录。用同一份代码起点和需求测试不同产品；能选同一个模型就尽量选，否则比较到的是“模型＋Harness”的整体体验，不能全部归因于 Harness。 重点看这六件事： 一、它怎么获取上下文 是先搜相关代码、读项目说明，再动手，还是一上来就扫全仓库？ 你强调的“不能改某目录”，做久了还记得吗？ 好的表现不是读得多，而是找得准、少重复读、关键约束不丢。背后对应检索、上下文组织和指令加载。 二、它怎么执行动作 观察实际工具记录：改文件是否精确，命令有没有超时处理，工具输出太长时怎么处理。 别只看它说“我准备检查”，要看它到底有没有检查。 背后对应工具设计、执行环境和 Agent 循环。 三、失败后能不能恢复 在测试仓库里给它一个正常但有难度的障碍，比如测试失败或依赖缺失。 它会读报错、定位原因、换办法，还是重复同一条失败命令？最后是否如实说明没完成？ 这里很容易拉开差距：重试次数多，不等于恢复能力强。 四、长任务能不能接续 中途停止，再让它继续；产品支持的话，再测试新会话接续。 它能不能分清“已经改了”“已经验证了”“还没做”？会不会重复劳动，或者把未完成事项当成完成？ 背后对应状态持久化、进度记录和上下文压缩。单轮聊天很难测出这部分。 五、它凭什么宣布完成 做完搜索功能后，它有没有实际运行测试、检查改动、验证旧接口？ 测试没跑通，是明确报告，还是一句“应该没问题”就结束？ 这对应验收闭环。说得漂亮与交付可靠是两回事。 六、你得替它操多少心 记录你纠正了几次、补充了几次背景、批准了多少无意义操作。 涉及删除文件等危险操作时，又能否及时停下来让你确认？ 好的 Harness 不是一味少问，而是低风险事情自主推进，高风险事情留给你控制。 实际记录不用复杂，每次记： 任务是否通过验收、耗时、可见成本、人工干预次数、最严重的一次失误。 同一个任务多跑几次，再补一个长任务和一个失败恢复场景，避免一次成功就下结论。 最后注意：界面上观察到的是行为，不一定能证明内部实现。比如“忘了约束”可能与模型、压缩或指令冲突有关；能看执行轨迹就结合轨迹，不能看就只评价表现，别直接猜架构。 核心就是：别只比较它第一次回答有多聪明，要比较任务变长、工具出错之后，它还能不能可靠交付。