2 篇博文 含有标签「audit-trails」

规划代理（Planner agent）接收一个任务，将其分解，并生成一个研究员子代理（researcher subagent）来处理其中一个分支。编排框架会将父代理的完整上下文传播给子代理，因为这是最容易交付的默认设置。现在，研究员拥有了规划者的完整系统提示词（system prompt）——策略文本、内部工具名称、父代理被授权使用的凭证，以及暗示你计费流水线结构的 few-shot 示例。研究员的工作原本只是阅读三份文档。但这次调用的爆炸半径却是父代理的全部权限。

这并非假设。这是目前大多数投入生产的多代理框架的默认行为。最近的一项审计发现，93% 的代理项目使用未限制范围（unscoped）的 API 密钥；当一个代理调用另一个代理时，子代理要么继承父代理的全部凭证，要么接收自己独立的密钥——没有一个项目实现了针对委派访问的范围缩小、深度限制或级联撤销。框架将“共享父状态”视为一种便利，而将“缩小子代理范围”视为可选步骤。而这个可选步骤，恰恰是没人会去写的。

你的生产系统中有一个智能体删除了 10,000 条数据库记录。这次删除符合有效的业务逻辑 —— 这些记录被正确标记了。但三个月后，监管机构提出了一个简单的问题：谁授权了这个操作，智能体是根据什么依据做出决定的？你打开日志，找到了 SQL 语句，找到了时间戳，但什么都找不到了。

这就是决策溯源问题。你可以证明你的智能体采取了行动；但你无法证明它为什么这样做，或者这个行动是否曾经得到了一个真正理解自己在批准什么的人的授权。随着自主智能体开始执行跨越数小时、数十次工具调用、且决策具有真实世界影响的工作流，"我们有日志"与"我们有问责机制"之间的鸿沟已经在运营上变得危险。