我构建了一个先请示再行动的自主个人代理。以下是这个决定的代价。

像 Instinct 这样的代理让"给助手发条消息，它就能帮你把事办了"成为了一个真实的品类。我构建了自己的版本，但押注不同：任何不可逆的操作（发送、支付、预订）都需要等人类说"是"。它连接邮件、Calendar 和网络，编辑真实的 Word/Excel/PowerPoint 文件，并通过 WhatsApp 向你更新信息。它不支持 iMessage 和电话，所以功能范围更窄。以下是我必须构建的东西，按"真希望早点做"的顺序排列： 1. **起草，而非发送。** 邮件被阅读、总结并起草，发送权始终留给用户。一次未经授权的操作就会让信任归零。 2. **Fail-closed（默认失败关闭）。** 代理每 15 分钟检查一次自己的授权。如果连续 72 小时无法连接到服务器，它就会停止响应。在无人监督时仍然继续行动的代理才是真正的风险。 3. **它不能修改自己的规则。** 核心规则由组织设定，而非用户或代理本身。这是提示注入攻击首先针对的目标。 4. **硬性排除。** 它绝不触碰 .env 文件、.ssh 文件夹或密码库。 5. **可审计但不担责。** 操作会被记录，密码和密钥被过滤掉。对话内容不被记录。 6. **WhatsApp 是一个安全问题，而非用户体验功能。** 未知号码只会收到一个请求配对一次性密码码的信息。吊销授权后，该号码在一分钟内就会停止被响应。 我害怕的失败是代理做了蠢事。真正击中我的失败是代理什么都不做。一个过时的凭据文件悄悄覆盖了长期有效的 token，每一轮对话都开始失败，代理沉默了大约六个小时。本应捕获这种情况的告警被代理自身的速率上限所吞没。我通过将认证固定到单一 token、按计划清除过时文件，以及在代理进程外部进行凭据健康检查来修复了这个问题。教训：仅靠 fail-closed 是不够的。一个沉默的代理必须对此大声告警。 最大的整体教训：用户不会问"它有多聪明？"，他们会问"如果它做了蠢事会怎样？"。治理最终成为了产品。我是构建者，且项目闭源，所以我不是在推销。我很好奇：你给代理添加的哪一条防护栏，是在它"坑"了你之后才加上的？