一直是你在最后检查 Agent 写的代码。这次反过来，给 Agent 的工作环境做次体检。
现在的 Coding Agent 已经能读需求、改代码、跑测试，提交 Pull Request。但“能做很多事”，不代表“能把事情做好”。
Agent 通常会在 “理解任务—执行操作—查看结果—继续调整” 之间不断循环，这就是 Agent Loop。真正可靠的 Loop，不只是让 Agent 一直行动，而是让它知道目标是什么、哪些地方不能动、怎么判断结果对不对，以及失败后该怎么办。否则，它可能改了很多代码、跑了很多测试，最后却无法证明任务真的完成了。
围绕怎么解决这个问题，行业在这两年里造出了一堆概念：prompt engineering、context engineering、harness engineering、loop engineering，最近又开始讨论 graph engineering。更替还在加速，最新两个只隔了一个月。海外社媒上有工程师自嘲：我们还在聊 loop，还是已经换 graph 了？中文社区的总结更省事：只要学得够慢，就不用学了。
这些名词，我们的建议是不用每个都追。名词一直在换，但指向的问题从来没变过：让 Agent 清楚目标、边界和验证方式，再把每次任务的经验留下来。该做的事也一直没变：每次 Agent 犯错，就沉淀一个机制，下次规避。
Qoder Desktop 全新推出的 Better Harness （Beta）可以先体检定位，再修复沉淀。检查方法来自 Qoder 团队内部实践，以及社区在这些领域反复验证过的做法，目标就是为 Agent 准备好项目上下文、相关的开发工具、验证方式方法，以及明确的安全范围，让每一次 Loop 都更接近可靠交付。
在最新版 Qoder Desktop 中，你可以进入 Better Harness，通过可视化界面启动分析并修复问题；也可以直接运行 /better-harness Skill。它会分析当前 Agent 执行任务的过程中，识别其中缺失或薄弱的关键要素，并帮助你明确下一步需要补齐和优化的内容。
Better Harness：如何诊断、改进并复验这个工作闭环？
Better Harness 检查的不是某一次回答写得好不好，而是支撑 Coding Agent 完成任务的整套 Harness：目标和上下文是否清晰、项目是否容易运行、权限是否可控、验证是否有效、交付是否安全，以及团队和 Agent 能否从任务中持续学习。
其主要的分析过程：
-
画出当前 Harness：识别目标、上下文、执行入口、反馈、交付和学习机制；
-
找到断点：说明哪一环缺少机制、接入、实际执行或结果证据；
-
选择最小改进载体：把问题交给最合适的 Rule、Skill、Hook、脚本、自动化或人工门禁；
-
修复并复验：限定修复范围，执行相关验证，再次运行 /better-harness 检查 Loop 是否真的改善。
分析时，Better Harness 会先由主分析流程收集原始数据，再交给三个相互独立的只读子 Agent 分别解读三类证据：Agent 自定义资产（Rules、Skills、Hooks 等配置是否完整可用）、真实的任务会话记录（Agent 在实际任务中做了什么、结果如何），以及项目的软件工程基础。三类证据独立收集、再统一汇总，避免结论互相污染。
Agent 自定义：从能力盘点到实际使用
在 Qoder 这一类 Coding Agent 中 Rules、Skills、Custom Agents、MCPs、Plugins、Memories 和 Hooks 等，都是帮助我们构建 Loop 的基础能力。为此，我们会在 Better Harness 中识别用户的这些自定义能力，如下图所示：
但基础能力并不代表 Loop 已经可靠：项目里有测试，不代表这次任务运行了相关测试；有 Skill，也不代表 Agent 在需要时真正使用了它。所以，我们也会进一步分析 Skill、 Rules 等的使用情况，以帮助用户找到一些影响 Loop 的上下文工程问题。
报告还会用 Qoder 的 Canvas 画布展示更细的数据，比如过去一段时间每个 Skill 的使用趋势：哪些被频繁调用，哪些装完一次都没用过。这类上下文工程问题修掉之后，还有一个直接收益是省 Credits：Agent 不用再把上下文花在重复摸索上。
Better Harness 也会尝试从历史会话中，分析是否可以提炼成一些规则、Skill，以加速用户的 Loop。但是，不是每个发现都应该变成 Skill，也不是每个重复任务都应该自动化。最后，我们会给用户一些可改进的意见和建议，如下图示：
对于识别出的改进机会，用户只需点击「创建修复方案」 Plan a fix，即可由 AI 生成并执行相应的修复方案。更重要的是，这些修复不仅服务于当前任务，还可以进一步沉淀为 Rules、Skills、Memories 等可复用的用户资产，持续增强你自己的 Agent Harness。
每一次任务分析，都不再只是一次性的优化，而是在不断完善你自己的 Harness：资产越丰富，Agent 越懂你和你的项目，后续 Loop 的质量和效率也会持续提升。
真实任务会话：还原 Agent Loop 的实际运行
但基础能力并不代表 Harness 已经可靠：项目里有测试，不代表这次任务运行了相关测试；有 Skill，也不代表 Agent 在需要时真正使用了它。所以，Better Harness 还会分析真实的任务会话记录（默认最近 30 天），看 Agent 在实际任务中到底做了什么、结果如何。
分析的基本单位是任务片段：一个用户目标，加上一个可观察的验收边界。在每个任务片段里，我们主要关注四类信号：
-
重复出现的工作流：同一类任务在多个片段中反复出现相同的步骤或纠正，可能意味着缺少一个 Skill、Rule 或脚本；
-
验证行为是否闭环：测试、lint、构建、回归等检查是否真的跑了、跑对了地方——重复运行检查不等于有效，还要看后续结果是否被接受；
-
摩擦点的归因：任务受阻时，问题来自 Harness、项目、模型还是需求本身，避免把所有失败都归咎于 Agent；
-
高影响的一次性事件：某次权限拦截、缺失的诊断入口或失败的恢复，是否实质改变了任务走向。
这部分分析由独立的只读子 Agent 完成，它只能读到脱敏后的事实摘要，不包含原始提示词、私有路径和密钥等敏感内容。结合这些信号，我们可以进一步分析 Skill、Rules 等的实际使用情况，帮助用户找到影响 Loop 的上下文工程问题，同时减少不必要的 credits 消耗。
项目工程基础：让 Agent 找得到、跑得起、验得准
除了 Agent 本身的使用方式，项目已有的软件工程基础也会直接影响 Loop 的质量。一个项目即使具备大量文档、脚本和测试，如果 Agent 找不到正确入口、无法顺利运行，或者不能根据失败结果判断下一步该做什么，这些工程能力也很难真正进入任务循环。
在这部分主要从五个方面观察项目是否具备支持 Agent 工作的工程基础：
-
找得到：面对一个具体任务，Agent 能否快速定位相关代码、模块边界、项目约束，以及需要执行的检查；
-
跑得起来：依赖、配置、构建和启动方式是否清晰，环境出现问题后，能否完成诊断、重置并重新开始；
-
反馈够快：代码修改后，是否有合适的检查和测试，及时告诉 Agent 哪里出了问题、问题可能来自哪里，以及下一步应该如何处理；
-
规则能落地：架构、安全、接口兼容性和数据库迁移等要求，是否通过工具自动检查，而不只是停留在文档或约定中；
-
改动可控：Agent 的变更边界是否明确，高风险操作是否需要确认，失败后是否能够回滚、恢复或安全退出。
例如，README 中写有测试命令，只能说明项目提供了测试入口；进一步检查脚本内容，才能知道它实际覆盖了哪些问题；只有在真实任务中运行这些检查，并根据结果完成修正，才能证明这条反馈路径真正进入了 Agent Loop。
让每一次 Agent Loop 都沉淀为下一次的能力
一次 /better-harness 分析不是终点。它会帮助你发现断点、生成修复方案，并在修复后验证新的 Rule、Skill、Hook 或脚本是否真正进入 Agent 的工作循环。
更重要的是，值得复用的经验会被沉淀为个人或团队的 Agent 资产，让后续 Loop 更稳定、更高效、更可控。