博客

构建 agent 系统的笔记

评估工具、编排模式、记忆设计及其背后的失败案例——在细节仍然新鲜时记录下来。

沙箱契约：Agent 在触碰生产端点前必须证明什么

Agent 的围堵是一份权限与验证契约，而不是一条 guardrail prompt。每个工具边界都需要一个 agent 在运行时无法协商的前置条件。

本地仲裁器决定哪些 Agent 步骤在手机上运行、哪些升级到云端，并以策略而非应用启发式的方式编码。

只有当每一次工具调用、凭证使用和状态转换在执行之前就被追加记录，Agent 的可问责性才可被证明，这也使日志成为运行时依赖。

对智能体进行身份验证并限定其令牌范围，并不能约束它在一连串工具调用中的行为。按轨迹评估的意图级策略，才是弥合组合缺口的控制手段。

Agent 之所以在无监控状态下运行，是因为框架输出的是日志，而非结构化 trace。解决办法是把可观测性作为构建期契约，而不是事后补上的工具。

大多数被归咎于模型推理的多 Agent 失败，其实是调度失败。无界扇出、没有背压、没有准入控制，会把一个集群变成重试风暴。

当入侵工具使用一组模型来选择下一步行动时，检测必须从痕迹转向行为——而智能体平台会继承其后果。

只有当升级契约明确时，将 agent 失败路由给人类才有效：移交什么状态、操作员可以更改什么，以及修正如何返回给 agent。

大多数 agent「记忆」故障其实是状态管理故障。对过往轮次的检索无法强制不变量；事务日志可以。