人工智能代理正迅速从令人印象深刻的演示走向实际工作。
它们阅读文档。它们总结对话。它们检查代码仓库。它们起草问题报告。它们准备回复。它们运行命令。有时，它们甚至会触及至关重要的系统。
这种转变给构建者带来了一个新问题：
如果代理要帮助运营真实的工作流程，你在哪里运行、观察和修复它们？
在 Armorer Labs，我们正围绕这个问题构建 Armorer。
Armorer 旨在成为代理的本地控制平面：一个用于运行代理、监视其行为、保留有用上下文以及在出现问题时进行恢复的地方。
Armorer Guard 是配套的安全边界：一个针对不应自动发生的代理操作的审批层。
本文是对我们正在解决的问题的草案性解释，并非声称我们已经解决了其中的每一个部分。
问题：代理正在成为操作员
一个简单的代理演示通常如下所示：
- 给代理分配一个任务。
- 让它使用工具。
- 阅读最终答案。
这对于实验来说没问题。
但真实的工作流程更加杂乱。
一个有用的代理可能需要：
- 浏览或检查不断变化的上下文，
- 记住产品细节，
- 与问题跟踪器协调，
- 为团队成员准备消息，
- 总结客户或社区信号，
- 运行本地命令，
- 重试失败的步骤，
- 并在执行敏感操作前请求批准。
一旦代理执行此类工作，重要的界面就不再仅仅是一个聊天框。你需要在代理周围建立一个操作层。
为何本地控制至关重要
许多代理工作涉及敏感上下文：
- 源代码，
- 产品战略，
- 客户对话，
- 凭据或账户边界，
- 内部规划，
- 未发布的草稿，
- 以及运营决策。
对于许多团队，尤其是小团队和创始人来说，本地优先的控制不仅仅是一种偏好。它是一种信任要求。
本地控制平面可以更轻松地查看：
- 代理被要求做什么，
- 它使用了哪些工具，
- 它依赖哪些证据，
- 它改变了什么，
- 它想做什么但被阻止做什么，
- 以及在哪里需要人类批准或重定向它。
目标不是让代理变得无能为力。目标是让它们可检查和可修复。
缺失的一环：审批边界
并非每个代理操作都应被同等对待。
以下操作之间存在巨大差异：
- 总结文件，
- 起草回复，
- 创建本地笔记，
- 打开拉取请求，
- 公开发布，
- 使用凭据，
- 联系客户，
- 或更改生产数据。
这些操作需要不同级别的权限。
这就是我们认为 Armorer Guard 所扮演的角色：代理操作的安全和审批边界。
一个实用的防护层应明确区分代理仅在起草草稿与即将执行具有外部或面向客户影响的操作之间的界限。
例如，一个安全的默认设置可能是：
- 允许起草草稿。
- 允许本地分析。
- 外部发布需要批准。
- 影响客户的操作需要批准。
- 使用凭据需要批准。
- 账户操作需要批准。
- 破坏性操作需要批准。
这种边界让代理能够提供帮助，而不会悄无声息地跨越人类
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
