助手、智能体与权限

识别系统如何行动

助手可以解释代码、提出计划或建议实现方案。智能体还可以使用工具，对环境采取行动。产品名称不能提供可靠的边界。有些聊天界面能执行命令，有些编程工具只能建议文本。

检查可用工具。有效的说明应列出系统可以读取、修改、执行和发布什么，还应说明每项操作使用的凭据和环境。

Anthropic 区分了预先定义的工作流，以及自行选择工具使用顺序的智能体。这个区分有助于解释工作如何开展，但不能决定某项操作是否安全。两种设计都需要明确的权限边界。

区分目标与许可

考虑一个虚构请求：“修复发票导出。”智能体可以检查代码仓库、重现缺陷、修改分支并运行检查。它也可能在环境中发现生产数据库的凭据。

目标不会授权所有可用操作。读取生产表、修改发票记录和部署新版本，各有不同后果。“完成任务”这类宽泛指令，并没有说明组织允许哪些操作。

开始工作前先明确边界。在本例中，智能体可以使用虚构数据和本地数据库，也可以创建 pull request。它不能访问生产记录或部署修改。这些操作由单独的发布流程处理。

用技术措施约束权限

指令帮助智能体理解任务。凭据和访问控制决定智能体实际能做什么。两者都要使用。

不要仅为了方便，就为只读任务提供写入凭据。测试环境不应在无人察觉的情况下继承生产访问权限。审查工具、身份和资源之间的连接。看似无害的命令，如果使用高权限身份，也可能造成重大影响。

明确何时必须停止

如果下一项操作超出权限，智能体需要有停止条件。证据不足时也需要停止条件。

在发票案例中，如果修复缺陷需要更正生产数据，就停止。如果要求的行为与已记录的会计规则冲突，也要停止。报告冲突、相关证据，以及需要负责人作出的决定。

为反复尝试设置时间或成本上限很有用，但这不能代替权限边界。十次获准的尝试与一次未经授权的部署，是不同的问题。

评估结果与操作记录

任务完成时，不要只看最终回答。审查修改过的文件、执行过的检查和剩余的不确定性。检查操作是否一直处于约定范围内。

有能力的智能体可以减少人工工作。组织仍然需要定义允许的操作、验证重要结果，并承担发布决策的责任。自主程度越高，这些职责就越重要。