定义
观察模式是一种运行 actor intelligence 的方式，在这种方式下，每次交互都会被分类和记录，但应用行为不会发生任何变化。不会因为 actor 结果而阻止、质询、减速或重路由任何请求。应用的响应会与未安装集成时完全一致。
在 Proof of Actor 中，观察模式是默认模式。安装集成会开始观察，而不是 enforcement。
为什么先从观察开始
每个应用都有自己的流量。浏览器采集器在仪表板上看到的信号，与在营销页面上看到的不同；API 看到的客户端，与 MCP server 看到的客户端也不同。在团队依赖 actor 结果之前，需要先了解它们在自身上下文中的表现。关于安全推出具备 actor 感知能力的策略的指南，以及我们关于为人类和 AI agent 设计应用级策略的文章，都是从这一步开始的。
观察模式让团队可以用真实数据回答实际问题：
- 覆盖率：在哪些 route 上集成看到了足够证据，哪里 Unknown 比例很高？
- 误报：当团队已经知道真实情况时，比如内部自动化账户或已知的集成合作伙伴，结果是否匹配？
- actor 组成：每个 route 上有多少 agent 流量，哪些 agent 是 verified，哪些是 declared？
- 延迟：每个 route 上这项检查增加了多少开销？
- 策略影响：如果上周执行了一条拟议规则，它会影响哪些交互？
实际工作方式
- 集成 受支持的服务端或浏览器集成到你关心的 route 上。
- 记录 将结果与你现有的日志和输出并列保存。
- 审查 将证据和分类结果与你已知情况进行对照。
- 预览 在不执行的情况下，用已记录流量预览候选策略。
- 启用 只有当团队确信该策略适合该工作流时，才在特定 route 上启用它。
每个 route 都可以独立地从观察切换到执行。团队可以在只读目录 route 上执行结构化 API 规则，同时让账户 route 无限期保持观察模式。
观察模式与故障处理
观察模式也是决定当结果延迟或缺失时，每个 route 应如何行为的最安全位置。提前选择某个 route 是fail open 还是 fail closed，意味着在任何东西被执行之前，这一决定已经被审慎制定、记录并测试过。
常见误解
"观察模式是试用版。" 它是负责任部署的基础。许多团队会永久让部分 route 保持在观察模式，因为仅靠分析就已经能回答他们的问题。
"观察意味着在执行之前没有价值。" 观察模式中的分析结果，包括 actor 组成、趋势和证据，往往是最早也是最重要的产出。
"执行要么全开，要么全关。" 策略是按 route 和风险等级分别配置的。观察和执行可以在同一个应用中并存。
Proof of Actor 中的观察模式
Proof of Actor 会让每个集成都从观察模式开始，而执行只会在应用所有者选择之后，且在应用自己的代码中发生。查看 工作原理 了解完整流程，或 申请提前访问 来开始观察你的流量。