原文来源：Agent Harness: Working with your data, safely
这是今年最有用的智能体工程文章之一，因为它拒绝陷入演示优先的自主性陷阱，而是聚焦于智能体应如何围绕真实的用户数据和真实后果来运作。
文章中强调的三个构建模块完全正确。
- 文件访问让智能体在用户拥有的数据中获得有用的基础支撑。
- 审批门控防止具有重大后果的操作被悄无声息地执行。
- 持久化记忆在保持控制的同时避免了重复交互。
大多数团队过度投资于工具的广度，而投资不足于权限语义。这是本末倒置。一个有十个工具但审批边界薄弱的智能体，不如一个只有三个工具但有可预测控制点的智能体有价值。
本文中最好的实用模式是分层审批策略：
- 始终要求审批——用于高影响工具，如交易或破坏性操作。
- 自动审批——低风险读取操作，以保持流畅性。
- 使用范围限定的常驻审批——在会话内对重复的可信操作使用。
这建立了一个健康的风险梯度。用户不会因为无害的读取而被频繁打扰，但当后果变得昂贵或不可逆时，他们仍然在决策回路中。
我也喜欢文件记忆和 Foundry 记忆之间的明确区分。团队应停止试图用一种记忆模型解决所有问题。粗粒度的显式文件工件非常适合用户可见的状态，如报告和监控列表。事实级别的记忆提取更适合偏好和对话上下文。将两者结合使用比假装其中任何一个足以解决所有问题能带来更好的结果。
我的个人观点：智能体质量的未来将更多地由安全性的人机工程学来衡量，而非巧妙的提示词。如果你的审批提示太嘈杂，用户会盲目地点击通过。如果你的记忆边界不清晰，用户会不再信任助手。如果你的数据访问默认是宽松的，安全团队会直接关闭项目。
对于采用此模式的 .NET 和 Python 团队，关键举措是将策略回调和审批规则视为核心业务逻辑，像其他关键代码一样进行版本控制和测试。不要让它们成为隐藏在示例代码中的临时 lambda 函数。
核心观点
赢得信任的智能体系统不是那些做得最多的系统，而是那些恰好做了用户想要的事——不多不少——并在风险升高时有明确的干预点的系统。
这就是令人印象深刻的演示与人们愿意委派实际工作的软件之间的区别。
