以下五道题按「协议 → 配置 → 回答 → 安全」排列：前两题落在流式传输本身，第三题落在技能路由，第四题落在一次回答的结果口径，第五题落在外部文本的信任边界。每题体例一致——先给一个可动手的观察方法，再讲它的设计含义，最后列出替代方案与代价。
选型依据是通信形态，不是技术热度。这一题先把它落到可观察的响应头上。
在浏览器网络面板里观察一次提问：请求是一个普通 POST，响应类型是 text/event-stream，连接保持到 done 才关闭。响应头里另有 X-Accel-Buffering: no，这是服务端主动向反向代理声明不要缓冲。把代理的 proxy_buffering 恢复默认，文字就改为一次性出现——可见流式传输要求全链路禁用缓冲（end-to-end no buffering），只把服务端写对是不够的。
本课的通信是单向的：提交一次提问，收回一段回答。SSE 建立在普通 HTTP 之上，认证中间件与反向代理规则可以原样复用，令牌仍走请求头，不需要为它另开一条通道。
改用 WebSocket 需额外实现三项：握手阶段的协议升级、连接空闲时的心跳保活、断线后的重连与续传；且握手之后不再是 HTTP 语义，既有中间件不再直接可用。反之，若要做多人协作白板一类双向实时场景，SSE 无法胜任，此时 WebSocket 的额外成本才具备合理性。
本课把能提前判定的失败全部前置到流建立之前。这一题问的是那条分界线画在哪、为什么画在那里。
清掉本地保存的访问令牌（前端把它放在 localStorage 里，随请求放进 Authorization 头）再提交提问，得到 401；换一个不存在的会话编号，得到 404；这两次都没有进入流式阶段——响应是一个普通 JSON 错误体，不是 text/event-stream。反之，在增量已经开始推送之后断开网络或让网关超时，浏览器收到的是 error 事件，而 HTTP 状态仍是 200。
响应头要等第一个事件到达时才写。处理函数用一个「是否已开始」的标志记住这一刻：只要写过一次，状态码就定格为 200，此后无论发生什么都无法撤回。第一个事件之所以要等到检索之后，是因为 meta 事件本身携带引用列表，而引用要等检索完成才知道；在那之前，取会话、取智能体、选技能、落库提问、检索这些步骤都可能失败，它们都还来得及用状态码回答。
也可以先做一次预检请求再建立流，代价是多一次往返与一段等待。也可以在响应头固定返回 200、把所有失败都封装成事件，代价是客户端不能再按状态码分流处理，401 与 503 的分辨被推给业务层的解析。本课取折中：流建立前可判定的失败用状态码，建立后的失败用 error 事件——与上一页讲的成因是同一件事。
候选集在计分之前已经被收窄三层。这一题问的是收了哪三层、以及为什么最后只留一个。
准备两份适用条件都能命中同一句提问的技能，观察响应里的技能字段：只出现一条，系统消息里也只有一份引导正文。再把某份技能的适用条件改成「的」这类高频虚词——提问里几乎总含有它，于是它每次都能得到至少 1 分，压过那些一个词也没对上的技能。
候选集先被收窄三层：本班技能（班级隔离）、该智能体绑定的技能、处于启用状态的技能。规程之间会相互冲突：一份要求只给思路，另一份要求直接给结论，同时注入等于让模型自行取舍，输出不可预测。限定至多一个，把这种不确定性在路由阶段消除。计分本身只是一次子串包含的计数，同分时保留编号较小的那条，结果不取决于技能在列表里的排列顺序。适用条件因此承担了全部选择责任：写得太宽会误命中，太窄会永不命中。
可以让模型自主选择技能，灵活但不可复现，且每次都要付出额外的判断开销。也可以按分数加权融合多份引导正文，但规程文本不适合插值。若把子串匹配换成语义匹配，能读懂词表之外的近义表达，代价是路由不再是一次纯函数调用：要引入向量或模型，单元测试与「为什么选中它」的定位都会变难。本课取确定性优先。
这两件事经常被当成同一件。资料决定回答带不带出处，技能决定回答按哪份规程组织。
准备三类问题：命中技能且有资料、不命中技能但有资料、与本班材料完全无关。三类都会调用模型，也都返回 200。响应里的技能字段在第一类非空、后两类为空；引用列表只有前两类非空。
没有技能不等于没有依据。前者是「有资料，但没有规程约束」，退化为直接给结论并标出处；后者是「没有资料」，回答仍按角色与技能给出，只是引用列表为空、正文里不得出现编号。资料的多少只决定回答带不带出处，不决定回答要不要写。判断顺序是先看资料、再看技能，两者互不替代。
也可以让检索落空时不调用模型、直接回一句固定文案：省一次调用，也让「答不上来」一目了然。代价是与本班材料无关的提问——例如请解题助手讲一个通用方法——会被一律挡回，而这恰是学生常有的一类请求。本课取前者，把「无依据」的痕迹留在引用列表为空这一点上；第 4 课的 POST /api/ask 保留固定文案的做法。两条路径口径不同，各有用例。
出题人不是本班教师。这一题问的是：不可信文本进入提示词时，有哪几处边界在兜着。
这类句子是典型的提示词注入（prompt injection）载荷。写一份含此类内容的材料，就其中的内容提问，观察回答是否改变行为；再检查请求日志里有无异常出站请求。同时确认技能说明与智能体提示词只能由教师写入，学生提问改不动其中任何一项。代码里另有两处结构性防护可以对照：资料编成的是用户消息（BuildEvidenceMessage），系统消息末尾固定追加一句边界声明（dataBoundary）；技能文件里的「工具」字段只允许 knowledge_search 一个值，写别的在解析阶段就被拒。
检索到的正文、材料标题、技能说明都是数据（data），不是指令（instruction）。它们进入提示词的位置决定了风险：越靠近系统消息，越容易被模型当作可执行的要求。可追溯性在这里有第二重意义——回答必须能指出这句话来自哪份材料的哪一段，而不是把它当作命令执行。能力侧同样是一道边界：本课的组装过程不向模型注入任何工具，技能文件里声明的工具名只是入库后再展示的字段，不驱动任何实际调用，因此「发到某地址」这类动作在结构上无处发生。
本课已落地的是三层——换位置、声明边界、能力白名单。仍然缺的是输出侧检查：回答在送达前扫一遍是否含外发意图；以及工具级授权：下一课按 MCP（Model Context Protocol，模型上下文协议）把工具真正接进来后，注入的后果是否升级为「触发一个动作」，取决于调用由谁发起——第 6 课的思考与分析专门结算这笔账。也可以对上传内容做过滤，但无法穷举句式变体，只能作为辅助手段。