模式矩阵 /模式白皮书/Perception
ADPS Agent 设计模式白皮书 · 模块总纲
感知模块 · 控制什么进入这一轮判断
输入边界、四层感知管线、Context Contract、正式模式与待研究问题。
范围：本页说明感知子系统的整体设计。P1 至 P4 的问题、机制和验证标准仍以各模式规范为准。
感知决定 Agent 在当前时刻能看到什么，以及哪些信号有资格影响后续判断。这里的输入不只包括用户消息和图片，还包括代码、日志、工具返回、事件、业务状态、项目规范与上一轮留下的工作产物。
模型窗口再大，也不能替团队完成输入治理。过多的材料会淹没当前目标，缺少来源和时间的信息会把旧事实带入新决策，未经隔离的外部内容还可能把攻击指令送进执行链。感知模块的工作，是在推理开始前把输入变成一份范围清楚、来源可查、预算可控的上下文。
感知从目标开始
2026-08-13 的 ADPS 感知模块研讨会上，多位专家从安全、研发效能、开源项目和游戏开发给出了相同的工程判断：先写清 Agent 要完成的决定，再反向确定它需要哪些输入。
一份 Context Contract 至少回答六个问题：
- 当前目标是什么，完成条件由谁定义。
- 哪些材料必须进入 context，哪些只保留句柄。
- 哪些状态需要在使用前刷新，哪些历史材料仍然有效。
- 每条输入来自哪里，作用域和访问权限是什么。
- 输入之间冲突时采用哪条优先级规则。
- 本轮没有看到什么，是否会影响结论。
感知 trace 需要同时记录 selected、deferred、dropped 和 unavailable。这样才能区分“系统没有发现材料”和“系统发现后决定不加载”。
四层感知漏斗
感知模块研讨会从多类生产场景中归纳出一条四层管线。它适合作为感知子系统的运行骨架：
| 层级 | 工程问题 | 典型处理 | 输出 |
|---|---|---|---|
| 信号接入 | 数据能否取得 | 协议适配、权限检查、幂等、超时与重试 | 带来源的原始信号 |
| 预处理 | 数据能否稳定使用 | 清洗、去重、归一化、格式校验、噪声过滤 | 规范化记录 |
| 语义聚合 | 离散信号怎样形成业务含义 | 实体关联、上下文补全、跨源对齐与原文回指 | 结构化事实包 |
| 事件判定 | 这组事实是否值得触发后续流程 | 分类、分级、置信度、规则校验 | 触发建议与理由 |
最后一层只给出事件类别、等级和触发建议。是否冻结账号、阻断发布或修改生产数据，由推理、行动与治理模块决定。感知层若直接写入业务动作，输入规则和业务决策就会绑在一起，后续很难独立评测与更新。
触发方式与执行拓扑的边界
信号可以通过回调事件、周期轮询、流式处理或人工请求到达。这些机制回答“什么时候有新信息进入系统”。任务启动后采用链式、路由、并行、编排、循环还是层级结构，仍由执行拓扑描述。
| 接入方式 | 适合的信号 | 主要代价 |
|---|---|---|
| 回调事件 | 代码提交、工单变化、告警 | 上游需要稳定事件契约和去重键 |
| 周期轮询 | 合规扫描、批量盘点、状态校准 | 延迟较高，大规模扫描消耗明显 |
| 流式处理 | 高频日志、遥测和消息流 | 架构、运维和重放机制更复杂 |
| 多源校验 | 高风险威胁、故障定位、全链路审计 | 语义对齐和证据冲突处理成本高 |
事件驱动因此不单独增加为感知模式，也不自动成为第七种执行拓扑。它是接入和触发机制，可以和 P1 至 P4 以及不同执行拓扑组合。
来源与模态是两个维度
研讨会对 P4 做了一次重要的边界修正。图片、文本、音频和表格属于不同模态；主机日志、网络流量、代码扫描和历史工单属于不同来源。多源输入可能全是文本，多模态输入也可能来自同一份 PDF。
生产实现应分别记录：
observation_id: obs_01K2...
source:
system: ci
channel: webhook
scope: repo://payments
modality: text
captured_at: 2026-08-13T12:10:00Z
valid_at: 2026-08-13T12:09:58Z
content_ref: artifact://ci/run-8842/log
transform:
method: error-normalizer-v3
parent: raw://ci/run-8842
trust:
integrity: verified
confidence: 0.94
来源字段用于权限、时效和交叉验证，模态字段用于选择解析器与表示。P4 当前保留“多模态融合”的目录名，同时把多源对齐列为正式机制；是否改名为更宽的“多源多模态融合”，等待更多独立案例再定。
四个正式模式的职责
| 模式 | 负责的问题 | 关键边界 |
|---|---|---|
| P1 上下文分诊 | 已知候选超出预算时，哪些加载、压缩、延迟或丢弃 | 目标、身份、安全约束和当前错误不能被普通材料挤出 |
| P2 语义压缩 | 已进入窗口的历史怎样缩小，同时保留决策依据 | 错误、被否决方案、业务数字和来源指针需要特别保护 |
| P3 渐进发现 | 不知道证据在哪里时，怎样从广扫走到精读和深追 | 每轮更新查询依据，并由证据、预算或无新增信号终止 |
| P4 多模态融合 | 不同模态和来源怎样解析、对齐与交叉核验 | 原始证据、转换方法和冲突必须保留，融合结果不能伪装成单一真值 |
四个模式可以接在同一条管线中。系统先接入并规范化信号，P4 处理不同表示和来源，P1 决定当前加载范围，P3 在信息不足时继续探索，P2 在长任务中回收已经消费过的上下文。
三个常见失效方式
输入越多，判断反而越差。 把能取得的数据全部交给模型，会扩大噪声、冲突和攻击面。感知范围应由决策目标反向约束，并通过回放检查漏报与误报。
感知与决策写在一起。 解析器一边清洗信号，一边直接决定业务动作，规则调整会牵动整条链。稳定接口应输出事实、分类、置信度和证据，业务动作另行准入。
上线后不再校准。 业务、系统架构、模型和数据源都会变化。感知需要自己的评测集，持续观察选择遗漏、错误压缩、零信号、触发延迟和跨源冲突。
安全边界
每接入一种外部来源，系统就增加一条数据与指令入口。工具描述、网页、文档、图片和日志都可能携带不可信内容。感知侧至少要做来源白名单、作用域校验、内容与指令分离、敏感字段处理和完整 trace；行动权限仍由工具准入、沙箱和审批控制。
这条分工很重要：感知可以标记可疑输入并降低信任等级，它不能仅凭模型判断给自己扩大权限。
AI 驱动软件工程为何从感知问题开始
在 Coding Agent 中，仓库就是主要环境。需求、架构决策、代码、测试、构建脚本和运行日志如果散落在聊天与个人经验里，对 Agent 来说等于不可见。新项目可以从一开始建立完整的规范链；存量项目更适合围绕当前改动逆向发现依赖、补齐局部文档和测试，再按可验收的垂直切片推进。
这部分讨论同时跨越记忆、行动、反思和治理，已经独立整理为AI 驱动的软件工程专题。感知总纲只保留它对上下文的直接要求。
2025 年 9 月，Anthropic 在面向 Agent 的 Context Engineering中把上下文定义为每轮推理需要持续整理的有限资源，并列出 compaction、结构化笔记和多 Agent 隔离等方法。2026 年 2 月，OpenAI 的Harness Engineering 实践把版本化仓库资产、可执行约束和反馈回路放到 Agent 可读环境中。两份工程记录与本次研讨会的共同点是：模型能力只在它能够读取、理解和验证的环境里生效。
仍需行业回答的问题
- P4 的目录名是否应从“多模态融合”扩展为“多源多模态融合”。
- 感知层输出到推理层的最小事实合同应包含哪些稳定字段。
- 外部输入的 prompt injection、来源污染和跨租户串数据怎样统一评测。
- 周期轮询、流式接入和事件回调如何共享同一套去重、时效与重放语义。
- 存量代码库的架构约束怎样变成 Agent 可发现、可执行、可持续校准的环境资产。
研讨会记录
本总纲吸收了 2026-08-13 感知模块第一次研讨会的讨论。主持人为黄佳；公开核心研讨嘉宾为张栋、黄湘龙、李庆丰和黄丞。