一篇于 2026 年 8 月 18 日上传至 arXiv 的研究，将 mission-critical infrastructure 里的 Agent harness 视为一个资源匹配问题。Harness 决定 Agent 可以看到哪些信息、使用哪些工具和采取哪些 action；研究团队指出，很多系统会对每个任务提供同一套完整 harness，但任务未必需要全部能力，这会增加资源消耗和不必要的暴露面。
作者先按底层系统的数学表示，把 mission-critical tasks 分类，再按信息数量和类型为不同 harness 排序。任务与 harness 的 mapping 来自两个来源：研究文献整理，以及受控 Agent execution 的量度。这个方法把「要不要把所有上下文塞给模型」改写成一个可以测量的匹配问题。
研究提出 map-guided escalation 演算法。它不是先开启 full provision，而是从 task-specific harness 开始；只有 Agent 的 self-check 失败，才扩大信息和工具供应。这个思路与 least privilege 相近，但多了一个 workflow 动态：权限和上下文不是永远固定，而是可以根据任务需要和失败讯号逐步增加。
作者在两个代表性任务评估方法。Liquid cooling 实验中，map-guided provisioning 的 Agent accuracy 由 full provision 下的 0.652 提升至 0.715，并以比 Reflexion 少 48% 的 tokens 达到相近效果。Power grid 实验则显示 full provision 仍然是 accuracy-optimal，但基于 mapping 的配置提供较低成本的选项。这些数字是论文的实验结果，不是所有 mission-critical domain 的保证。
研究把结果总结成一条 domain-dependent 的 accuracy-cost Pareto frontier，而不是一个适用于所有任务的最佳 harness。对于 AI workflow 团队，这个结论很实用：Agent 的工具权限、背景资料和 context window 应该跟任务风险、验证能力和成本一起调校，而不是单纯追求最完整的上下文。
实践上，采用这种设计要先处理 self-check 是否可靠。如果 Agent 不知道自己缺少关键资料，系统可能不会触发 escalation；如果 escalation 没有限制，Agent 又可能用反复失败换取过宽的权限。因此需要明确的任务分类、可观察的失败原因、上限、人工升级点和恢复策略。这段是根据研究结果作出的工程解读，不是论文已经验证的通用产品方案。
这篇 preprint 的重点不是叫企业把 Agent 的能力一律缩小，而是提醒团队把 harness 当成可配置的 workflow layer。对高风险系统，最小必要信息和工具可以先限制 blast radius；对需要全局上下文的任务，系统也应有证据支持何时值得提供 full provision。
