做 Agent 项目时有一个很矛盾的地方。 系统出了问题，程序员最希望看到完整的执行过程。模型调用了什么工具，输入了哪些参数，接口返回了什么，每一步耗费了多… · @UPing123zzz · TwKit

@UPing123zzz

做 Agent 项目时有一个很矛盾的地方。 系统出了问题，程序员最希望看到完整的执行过程。模型调用了什么工具，输入了哪些参数，接口返回了什么，每一步耗费了多少 Token，最好全部记录下来。 但如果真的把这些东西原封不动地保存，可能又会制造一个更大的问题。 因为 Agent 处理的内容未必都是可以随便存储和查看的信息。 比如企业知识库可能包含内部文件，招聘 Agent 会读取候选人的个人信息，云端自动化工具可能接触 API Key 和临时访问凭证。 如果为了调试方便，把完整请求、用户资料、模型上下文和工具返回内容全部写进日志，最后可能出现一种非常讽刺的情况。 主系统的权限控制做得不错，日志平台却保存了大量原始敏感数据。 尤其是 Agent 的执行链路比较长，一个任务可能连续调用十几个工具。 同一份数据在不同工具之间传递，日志里可能出现多份副本。开发者为了排查一次错误，反而把信息复制到了更多地方。 所以我最近觉得，Agent 的可观测性需要认真设计。 调试时真正需要知道的可能是任务编号、调用了哪个工具、执行状态、耗时、错误类型，以及必要的输入参数摘要。 不一定每次都要保存完整用户资料。 需要记录具体内容的场景，可以结合脱敏、访问控制、保留期限和必要的审计机制。敏感信息应该在进入日志前就被处理，而不是等出了问题再去删除。 另外，我觉得执行记录应该尽量跟真实操作对应。 某个 Agent 说自己查询了数据库，最好能找到实际查询的调用记录；说文件已经上传，就应该有存储系统返回的结果。 这样日志才不只是模型的工作日记而是可以用于检查系统行为的证据。 以后 Agent 会处理越来越多真实业务，权限和审计问题也会越来越具体。 程序员需要让系统足够透明，方便发现错误，但同时不能让透明本身变成新的数据泄露风险。 让 Agent 做事很重要，知道它究竟做了什么，并且安全地保存这些证据，同样重要。

曝光 174 · 评论 4 · 点赞 1 · 书签 0