加密的子代理提示仍需本地审计追踪
摘要
本文认为,虽然加密的子代理提示能保护消息内容,但仍需本地审计追踪,以便调试和重建代理行为。
我在阅读 openai/codex 上关于加密 MultiAgentV2 消息的 issue 时,真正让我担心的并不是加密本身,而是缺少审计日志。如果代理将工作委托给子代理,我关心的不仅仅是最终 diff 能否通过测试。我还想知道子代理实际被要求做什么。没有这一点,调试会很快变得奇怪:是父代理分配错了任务?子代理忽略了任务?还是系统路由正确但隐藏了有用的中间步骤?这些是不同的失败场景。如果唯一可读的输出是最终答案和工具调用,那么你就缺少了解释工作为何偏离方向的关键信息。我理解加密传递的存在理由——在托管系统中保护消息内容确实有实际需求。但对于在我自己的仓库或机器上运行的代理,我仍然希望有一个本地可读的审计副本。它不需要暴露给模型,也不需要发送到其他服务,只需写入某个地方,以便在运行出现异常时我能事后检查。在生产环境中,我认为这比人们意识到的更重要。困难的部分不仅在于为代理授权,更在于能够在它处理了一堆文件后重建发生了什么。
相似文章
当智能体使用人类凭证运行时,如何保留审计跟踪?
讨论了当AI智能体使用人类凭证运行时,维护审计跟踪的挑战,强调了安全和问责问题。
AI代理需要审计追踪而非更多自主性
AI代理需要审计追踪以实现透明度和信任,而非仅仅专注于自主性,用户需要看到代理执行的每一步操作。
你的语言模型不需要更好的提示——它需要一个代理控制框架
文章讨论了Agent控制框架工程(Agent Harness Engineering)的必要性,包括工具验证、上下文管理、护栏、遥测和验证循环等结构化系统,以使LLM代理在生产中可靠,并认为仅靠更好的提示是不够的。
从删除生产数据库的代理中得到的错误教训
文章认为,从Cursor/PocketOS事件中得到的教训不仅仅是权限护栏,而是需要为AI代理建立会话历史和信任档案,以早期检测行为故障。
你是如何测试本地编码智能体的工作门以防止提示注入的?
关于测试本地编码智能体的工作门以防止间接提示注入的讨论,重点关注智能体工作流程中的证据信任和验证挑战。