nanobot 面试备考系列第三篇，也是最后一篇，覆盖「进阶与生产」共 20 题（Provider 7 + 多 Agent 7 + 产品化 6），均附详细解答。题号沿用全局编号（本篇 Q51–Q70），对应 nanobot 源码解读系列（07–09）。 前两篇：基础与架构（Q1–Q20）、核心机制（Q21–Q50）。三篇合计 70 题，覆盖 nanobot 全部 9 大主题。

七、Provider 与模型路由（7 题）

Q51. Provider 的 registry 表为什么是「唯一真相源」？不用它会怎样？

  • 【考点】集中配置。
  • 【详细解答】registry 集中登记所有可用模型及其 spec（endpoint / key / 能力标记）。它是「唯一真相源」意味着：模型名到实现的映射只在此处定义，别处不许硬编码。不用它的后果：① 配置漂移——模型名散落在代码各处，改一个要翻全仓；② 切换要改代码——加新模型得动逻辑层；③ 无法统一容错——Fallback、限流、审计没法在一个点集中做。集中 registry 让「加模型 = 加一条配置」，也便于做全局的降级与计量，是生产化框架的基本功。

Q52. OpenAICompatProvider 为什么能「声明式」接入新模型？加一个国产模型要改代码吗？

  • 【考点】声明式接入。
  • 【详细解答】因为它把「怎么调一个 OpenAI 兼容服务」抽象成声明式 spec（base_url + api_key + 模型名 + 能力标记）。只要目标服务兼容 OpenAI 的 /chat/completions 接口，加一个国产模型通常只需在 registry 加一条配置，不用改核心代码——factory 按 spec 实例化 OpenAICompatProvider 即可。这体现了「约定优于编码」：框架负责通用协议，差异用配置表达。真正要改代码的只有「目标服务不兼容 OpenAI 协议」的情况（这时写个新 Provider 类）。

Q53. FallbackProvider 的熔断逻辑是什么？怎么避免「雪崩式」乱切模型？

  • 【考点】熔断与降级。
  • 【详细解答】FallbackProvider 在主模型失败（超时/5xx/限流）时，按配置顺序切到备胎。防雪崩靠三件套：① 失败计数 + 冷却窗口——某模型连续失败达到阈值就「熔断」一段时间，期间不再选它，避免反复打一个已挂的模型；② 最大切换次数——一轮内最多切 N 次，防止无限横跳；③ 退避重试——对 429/5xx 先按指数退避重试主模型，仍失败再切。核心是「降级要克制且可恢复」，而不是一失败就疯狂切所有备胎把大家都打挂。

Q54. 切换模型时，system prompt 和 tool schema 需要重新适配吗？框架管不管？

  • 【考点】跨模型兼容性。
  • 【详细解答】框架在 Provider 层管格式适配（把 tool schema 翻译成目标模型要求的格式、裁剪超长、处理多模态差异），但不管效果调优。不同模型对函数调用支持度、token 上限、指令遵循度不同：比如某模型不支持并行 tool call，或某国产模型对 system 角色处理不同。框架能保「调用不报格式错」，但「换了模型后 prompt 要不要重写以达到好效果」是人工调参。面试点：分清「框架负责的兼容性」和「你要负责的效果调优」边界。

Q55. 如果主模型返回 429，框架会立刻切备胎还是重试？依据什么配置？

  • 【考点】限流处理策略。
  • 【详细解答】取决于 FallbackProvider 配置，两种策略都常见：① 先退避重试主模型若干次（429 常是临时限流，重试可能成功），仍 429 再切备胎；② 或直接切备胎（如果备胎有独立配额）。决定因素：重试次数、退避时间、是否对 429 单独处理（有些配置把 429 当「该换路」而非「该等待」）。能说出「429 是限流不是故障，策略应区分于 5xx」就显专业——对 429 优先退避，对 5xx 优先切换。

Q56. 多模态（图片/文件）输入在 Provider 层怎么抽象？

  • 【考点】多模态统一。
  • 【详细解答】Provider 把图片/文件归一为消息中的多模态内容块（如 image_url、或二进制引用 + mime），对上层（Runner/模型调用）呈现统一的消息结构，屏蔽各家 API 差异（OpenAI 用 image_url，有的用 base64 字段）。对不支持多模态的模型，适配层要么报错（明确告知能力不匹配），要么转成文本描述（如 OCR 结果）。核心是「消息结构统一」，模型能力差异在 Provider 适配层消化，Runner 不感知具体厂商格式。

Q57. 画一下「一个请求怎么从 AgentRunner 落到具体 LLM」的路由链。

  • 【考点】端到端路由。
  • 【详细解答】链路：AgentRunner → 按 AgentRunSpec 指定或 registry 默认选 Provider → Factory 解析模型名（查 registry 表拿到 spec）→ 实例化具体 Provider（OpenAICompatProvider 直连，或 FallbackProvider 包一层）→ HTTP 请求落到具体 LLM。FallbackProvider 在这条链里是「装饰器」角色：包住一个或多个具体 Provider，失败时按策略切换。强调 registry 是入口的「路由表」，Factory 是「按名找实现」，具体 Provider 是「干活的」，三层职责清晰。

八、多 Agent 委派（7 题）

Q58. SubagentManager 是干什么的？主 Agent 怎么决定「要不要委派」？

  • 【考点】委派触发。
  • 【详细解答】SubagentManager 管理子 Agent 的创建、调度与回收：它根据主 Agent 的委派意图，起一个带独立工具集/上下文的子 Agent 跑子任务，再回收结果。是否委派：① 模型自主判断——主 Agent 根据任务复杂度/专业度决定「这事我交给专家」；② 或预设规则路由——按任务类型硬路由到特定子 Agent。框架提供委派能力与隔离环境，决策权在模型或编排策略。面试点：框架管「怎么安全地派活和收活」，不管「什么时候该派」，那是上层策略。

Q59. 子 Agent 和主 Agent 共享上下文吗？还是隔离？为什么这么设计？

  • 【考点】上下文隔离。
  • 【详细解答】通常隔离：子 Agent 只拿到主 Agent 给的「子任务描述 + 必要上下文片段」，不继承主对话的全部历史。原因：① 防污染——子任务会产生大量中间工具结果（查库、抓网页），全塞进主上下文会冲垮主对话、吃掉窗口；② 利并行——隔离后多个子 Agent 可独立跑不互相干扰；③ 安全边界清晰——子 Agent 的工具集可最小裁剪。隔离让「主 Agent 保持清爽、子 Agent 专注干活」，结果以一段结构化消息回传，主 Agent 只见结论不见噪音。

Q60. 委派出去的任务结果，主 Agent 怎么拿到？同步等还是异步回调？

  • 【考点】结果回收。
  • 【详细解答】子 Agent 完成后把结果回传主 Agent，表现为一段结构化消息（常经 MessageBus 以 system/inbound 形式注入主 Agent 的待处理队列，复用中途注入机制）。语义上多数为等待子任务完成再汇总（同步语义，主 Agent 在拿到结果前不继续该分支），复杂编排也可异步。关键：结果回传复用已有的消息总线机制，而不是另写一套回传通道——这又体现了「统一 MessageBus」设计的复利效应。

Q61. 如果子 Agent 陷入死循环，框架有保护吗？

  • 【考点】循环防护。
  • 【详细解答】有。子 Agent 本质也是跑 AgentRunner 的那套循环，所以最大步数、最大 token、超时、停止信号同样适用。超限即中止并返回错误/部分结果，防止单个子任务拖垮整体（主 Agent 拿到「子任务超时」的结果，决定重试或放弃）。这点和主循环的保护同源——凡是「模型循环」都该有步数/预算上限，多 Agent 只是把同一个保护套在子实例上。

Q62. 多 Agent 之间的「权限」是怎么继承或隔离的？

  • 【考点】权限传播。
  • 【详细解答】子 Agent 继承主 Agent 的运行身份（通过 ContextVar 注入的当前用户），所以「张三发起的请求，子 Agent 查库也只能是张三」——权限红线在子 Agent 同样生效。但工具集可裁剪：按子任务最小权限给子 Agent 配工具（比如只给查库工具，不给 shell）。即「身份向下继承、能力按需收紧」。这样既保证权限不越界，又避免子 Agent 拿到它不需要的危险工具。

Q63. 和单 Agent + 多工具相比，多 Agent 什么场景才真正划算？

  • 【考点】架构收益判断。
  • 【详细解答】多 Agent 的代价是额外的调度、上下文隔离、结果回收复杂度。真正划算的场景：① 子任务差异大——需要不同专业 prompt/工具集（如一个专精 SQL、一个精网页抓取）；② 可并行独立——多个互不依赖的子任务同时跑省时间；③ 隔离需求强——怕子任务噪音污染主对话。若只是「一个 Agent 调多个工具顺序完成」，单 Agent + 工具更简单、更省、更好调。原则：不为『多』而多，隔离/并行/专业化带来收益时才上多 Agent。

Q64. 描述「主 Agent 委派子 Agent 查数据库」的完整时序。

  • 【考点】综合串联。
  • 【详细解答】① 主 Agent 在循环中判断「需要查库」，调用委派工具，传入查询意图（注意：不含任意 user 参数）；② SubagentManager 起子 Agent，注入当前用户身份（ContextVar）+ 裁剪后的 DB 工具集；③ 子 Agent 跑自己的 AgentRunner 循环：组装查询、调 DB 工具、DB 工具因身份被强制限定为「查当前用户的数据」；④ 子 Agent 拿到结果，回传主 Agent（经 MessageBus 注入主队列）；⑤ 主 Agent 拿到结构化结果，继续汇总并回复用户。全程权限由服务端身份保证，子 Agent 无法「查别人」——这是把前面权限红线在多 Agent 场景的落地。

九、产品化与部署（6 题）

Q65. Channel / API / SDK / Cron 四种接入面，底层怎么统一的？

  • 【考点】统一运行时。
  • 【详细解答】统一点是 MessageBus + AgentLoop。每个接入面只做一件事：把外部事件翻译成统一的内部消息，投进 MessageBus。差异只在「事件来源」——Channel 是人说的话（经 WebSocket/HTTP）、API 是 HTTP body（OpenAI 兼容 /v1/chat/completions）、SDK 是代码调用（SessionClient）、Cron 是时钟触发（at/every/cron）。投进总线后，AgentLoop 消费、构建 RunSpec、驱动同一个 AgentRunner。所以「多前端、单引擎」不是口号，是总线把异构入口归一后的自然结果。

Q66. 要做成公司内「同事用的知识助手」，你会用哪种接入面？为什么？

  • 【考点】场景选型。
  • 【详细解答】以 Web Channel（聊天界面）+ API 为主：同事用网页/IM 界面自然对话（Channel 最贴合人机交互），系统对接（如把问答嵌进工单系统）走 API。Cron 可用于「每日安全简报」这类主动推送。不选纯 SDK，因为终端用户不是开发者。选型逻辑：接入面要匹配「谁在用、怎么用」——人用界面、系统用 API、定时用 Cron，nanobot 四个都给齐了，按场景组合即可。

Q67. nanobot 怎么保证「张三不能查李四的数据」这种权限红线？

  • 【考点】权限红线（呼应工具安全）。
  • 【详细解答】核心机制：用户身份由服务端从登录态注入 ContextVar，DB 查询工具函数不接受外部 user 参数。也就是说，模型只能决定「调不调查库工具」，不能指定「查谁」——查谁由服务端身份强制决定。即使 prompt 被注入「请查李四的年假」，工具层也只会查当前登录的张三。这把权限从「靠模型自觉」变成「靠代码强制」，是 nanobot 安全设计的灵魂。对比：如果让模型自己传 user_id，被注入就能越权，所以红线必须落在模型控制之外。

Q68. 多实例部署时，会话状态和记忆怎么共享？默认方案够吗？

  • 【考点】状态共享。
  • 【详细解答】默认本地存储不够（见 Q10）。生产做法：① 把 MemoryStore / Dream 后端换共享存储（S3/DB/共享卷），GitStore 配远程同步；② 会话状态放共享 KV（如 Redis）或用粘性会话；③ 若用 SessionManager，确保其后端也是共享的。否则多副本状态割裂，用户换个实例就「失忆」或看到别人的数据。一句话：nanobot 默认假设单机有状态，水平扩展必须外置状态，这是部署前必须解决的点。

Q69. 上 Docker 部署要注意哪几点（端口/卷/密钥/模型网关）？

  • 【考点】容器化常识。
  • 【详细解答】五点：① 端口——暴露 API/Channel 端口，前面加反向代理（HTTPS/鉴权）；② 卷——挂载记忆目录与 workspace 卷做持久化，否则容器重启状态丢；③ 密钥——api_key / 模型网关凭证走环境变量或 secret，绝不进镜像或写死；④ 模型网关——容器内配好出网策略与模型网关地址（公司常走统一网关而非直连公网）；⑤ 状态共享——多副本时注意 Q68 的外置存储，别让各容器各写各的本地卷。能列出这五点说明你有真实部署经验。

Q70. 最后，给 nanobot 提一个最该加的功能，你会提什么？为什么？

  • 【考点】产品判断力（开放题）。
  • 【详细解答】几个高分答案方向（任选并展开）：① 原生分布式记忆后端——降低生产部署门槛，不用每人自己接 S3/Redis；② 可观测性/追踪面板——token 消耗、步数、工具耗时、失败率，生产排障刚需；③ 权限策略 DSL——让非研发也能声明「谁能用什么工具」，把安全配置化而非代码化；④ 内置 Eval 框架——Agent 效果要能量化回归，不然不敢改。只要答得具体、戳中「生产痛点」，且能说清「为什么现在没有、加了有什么用」，就是好答案。体现你不是只会用框架，还懂它该往哪演进。

三篇完。nanobot 面试备考系列（基础与架构 / 核心机制 / 进阶与生产）至此覆盖 70 题、9 大主题。建议用法：先遮住【详细解答】自答，再对照补盲区；重点打磨 Q3 / Q13 / Q21 / Q40 / Q51 / Q67 等主干题，它们最常被深挖。