Harness 11类职责全景清单
如果把Harness抽象成厂商无关的运行底座，它至少要管11类职责：
任务规格、上下文选择、工具访问、项目记忆、任务状态、可观测性、失败归因、验证、权限、熵审计、干预记录。
这不是功能清单，而是Agent上生产前的风险清单。
输入侧有两类职责：
Task Specification定义"做什么"，Context Selection定义"看什么"。
没有任务规格，Agent容易越界；没有上下文选择，Agent要么看不够，要么被噪音淹没。
动作侧有三类职责：
Tool Access管工具授权限时，
Project Memory管知识隔离更新，
Task State管长任务恢复点。
如果这三件事只存在对话里，一次context reset就可能让任务失忆。
观察侧有Observability和Failure Attribution：前者让你看见Agent做了什么，后者让你分清失败在哪里——模型错、工具错、上下文错、权限错，还是Harness没托底。验收侧有Verification和Permissions：验证管"做对没"，权限管"该不该做"。只验证结果可能放过危险路径，只管权限可能产出错误结果。
治理侧有Entropy Auditing和Intervention Recording：前者管Agent留下的技术债，后者管人什么时候接管、接管了什么。生产系统不是只记录成功路径，越是需要人工干预的地方，越应该被结构化记录。上线前用11行清单自检：任务有边界吗？上下文可控吗？工具有策略吗？缺哪一项，就是哪一项的生产风险。
企业Agent Agent harness HarnessEngineering AgentOps