大家好，我是十三！欢迎来到十三Tech。
上一讲聊了感知层为什么是入口闸。这一讲进入感知模块的第一个具体模式：上下文分诊。
看完之后，它给出的判断比我预期的狠。
上下文窗口是急诊室，不是数据库。
数据库追求完整保存，急诊室追求优先处置。Agent 该看什么，不应该由"哪个材料刚好被检索到"决定，而应该由一套明确的分诊规则决定。多塞信息看起来稳，实际上带来三个问题：关键证据被挤到上下文中间、模型注意力被无关材料稀释、token 成本被迅速拉高。
一、P0 到 P3：四级优先级
课程给的方法叫四级分诊。按优先级给候选信息排级，再决定它以原文、摘要还是 handle 的形式存在。
| 级别 | 什么内容 | 处理方式 |
|---|---|---|
| P0 | system prompt + 当前任务 + 安全规则 | 原文，永远加载 |
| P1 | 最近修改的文件 + 错误堆栈 + 工具结果 | 原文片段 |
| P2 | 较早的对话 + 背景文档 | 压缩摘要 |
| P3 | 通过工具可获取的全量数据 | 只挂 handle |
关键洞见在 P3：不预加载，按需展开。 上下文窗口因此变成一个虚拟内存系统。同一个登录 bug，分诊之后：bug 描述和错误堆栈进 P0，auth.py 相关函数进 P1，历史聊天压缩成 P2，整个代码仓库只挂 handle 在 P3。Agent 不是"知道得更少"，而是先看最该看的东西。
二、这不是新东西，是虚拟内存的复刻
沿 Karpathy 的类比——LLM 是 CPU，上下文是 RAM——四级分诊对应操作系统的内存管理。
P0 是不能换出的热页，P1 是当前任务的工作集，P2 是压缩后的背景页，P3 handle 就是页表项——本身很小，但能在需要时把原文拉回来。
这套映射一旦立住，所有工程决策都顺了。为什么 P0 必须常驻？实时任务不能被换出。为什么 P3 不预加载？冷数据应该 lazy loading。为什么常驻规则不能太长？内核态占多了，用户态就少了。
三、分诊的三种来源
把课程里 8 个框架的横切对比收束后，作者给出三种分诊来源。
第一种是人知道什么重要——CLAUDE.md / AGENTS.md，由开发者人工写规则。第二种是代码结构显示什么重要——Aider 的 RepoMap 从仓库里自动抽符号骨架加 PageRank 排序。第三种是系统 schema 强制什么必须存在——runtime context 加 middleware，把身份和权限做成强制字段。
成熟 Agent 系统往往三种综合运用：用规则文件锁住 P0、用算法发现 P1/P2、用 schema 保证身份和权限不会丢。
四、分诊 = 感知 + 权限
这一讲对我最大的冲击是它把分诊和多租户隔离打通了。
在多租户 SaaS 客服场景里，200 多个租户，单租户约 30 万 token，合计 6000 万 token。任何模型窗口都装不下。
分诊方案里，tenant_id 不应是普通元数据，而应是 P0 级硬约束——任何 P1/P2/P3 资源加载前都要校验它是否属于当前租户。不一致直接拒绝，不交给模型判断。P3 handle 也要带租户前缀：manual_section://acme/billing 比 manual_section://billing 安全得多。
这就是服务端做行级安全、做数据权限隔离时同一套思路。Agent 的感知层在工程现场会和数据权限、租户隔离深度耦合。 这是过去做 LLM 应用的人很少重视、但架构师必须接管的部分。
五、三个指标把分诊变成工程对象
分诊最终能不能变成工程对象，取决于三个指标。
| 指标 | 含义 | 异常信号 |
|---|---|---|
| budget_usage | tokens_used / budget | p99 突然升高 → 某类任务信息量压垮当前策略 |
| p0/p1_dropped | 关键层丢失计数 | P1 经常被丢 → 预算太紧或优先级规则错 |
| p3_hit_rate | 实际读取的 handle 数 / 暴露的 handle 数 | 过低 → 挂了太多没用的 handle；过高 → 该在 P2 的被降到了 P3 |
这和我做 SRE 看 CPU 利用率、错误率、缓存命中率是同一个动作——给一个抽象决策过程装上性能计数器。
TriageDecision 不要只写成一行文本日志，最好是结构化 trace：item_name / priority / decision / reason / tokens_used / budget。分诊是一次有约束的工程决策，有决策就必须留审计入口。
这和我做服务端时加 APM、加链路追踪是同一个道理：没有可观测性就没有工程化。感知层的分诊也不例外。
课程入口
关于十三Tech All in AI Agent方向的架构师，专注AI工程实践。 相信AI是程序员的最佳搭档，帮助每一位开发者驾驭AI。
联系方式：569893882@qq.com GitHub：@TriTechAI
