影石 Insta360 三面：Agent 幻觉归因与端云分工

《面试题目》

1. 请你先做一个自我介绍，然后讲讲你这个 Agent 是独立完成的还是参考开源？
2. 参考了哪些开源项目？为什么选它？和你的场景匹配吗？
3. 项目中最困难的问题是什么？你是怎么解决的？具体说说。
4. Agent 出现幻觉怎么定位？幻觉分哪几类？怎么区分？
5. 事实性幻觉怎么解决？工具选择错误怎么解决？参数错误呢？
6. 参数构造错误怎么解决？分别用什么手段？哪种最有效？
7. 高风险操作怎么保证 Agent 不越权？确定性程序怎么校验？
8. 确定性程序怎么校验？谁来兜底？模型还是代码？
9. RAG 优化做过哪些？LangChain 踩过什么坑？怎么解决的？
10. 你怎么做 Agent 评测？评测集怎么构建？多少条？覆盖哪些场景？
11. 人工评测标准是什么？怎么保证一致性？多少人评？
12. 模型自动评测怎么做？同模型评测同模型有什么问题？怎么避免？
13. 如果让你设计一个自动化评测框架，你会怎么做？怎么保证可信？
14. 你怎么理解 Harness？它包含哪些模块？核心职责是什么？
15. 状态管理怎么做？工具调度怎么保证稳定？错误处理呢？
16. 错误处理怎么做？重试和熔断怎么设计？阈值怎么定？
17. 长任务怎么防行为漂移？上下文衰减怎么处理？你遇到过吗？
18. 多 Agent 协作怎么保证结果可验证？怎么避免自然语言不确定性？
19. 怎么避免自然语言带来的不确定性？有没有结构化协议？
20. 你怎么控制成本？有哪些具体策略？省了多少？怎么算的？
21. 如果让你设计一个硬件场景的 Agent，你会怎么做？和纯软件有什么区别？
22. 设备数据怎么接入？实时性怎么保证？延迟要求多少？
23. 端侧和云端怎么分工？哪些放端侧？哪些放云端？为什么？
24. 如果网络不好，Agent 怎么降级？用户体验怎么保障？
25. 你怎么做压力测试？高并发怎么处理？瓶颈在哪里？
26. 你怎么做可观测性？Trace 怎么设计？记录哪些字段？
27. 线上故障怎么排查？先看什么？怎么定位到具体环节？
28. 你怎么跟进 Agent 领域的最新进展？最近看了什么？
29. 你 DeepFlow 多智能体文档生成项目里，多 Agent 怎么协作的？
30. 文档生成质量怎么评估？怎么保证不胡编？有没有事实校验？
31. 反问：团队现在 Agent 落地到哪一步？
32. 手撕：余弦相似度计算，追问 4096 维、100 万对向量怎么优化。

《参考解析》

开源选型与项目难点的讲法。 「独立完成还是参考开源」这类问题考的不是忠诚度而是工程判断：从零写一个 Agent 循环并不难，难的是状态、权限、可观测、评测这些底座，所以拿开源做参照、把自研投入到业务真正差异化的部分，是更合理的策略。回答时应该给出明确的取舍理由：选型看四件事——控制流是否透明可改（黑盒框架在排查问题时很痛苦）、工具与模型的接入是否解耦（换模型不改业务代码）、状态是否有外部持久化（进程重启能否续跑）、以及依赖与运维成本。和场景的匹配度要落到具体点：文档生成场景重长上下文与结构化输出，工业场景重工具调用可靠性与时序，硬件场景重低延迟与离线可用。讲最困难的问题时，用「现象—定位过程—根因—方案—验证结果」的叙事结构，最忌讳只讲结论；能有可量化的前后对比（成功率从多少到多少、耗时降了多少）最有说服力。

幻觉的分类、定位与针对性手段。 工程上把幻觉分四类更实用：事实性幻觉（编造不存在的事实或引用了不存在的文档）、工具选择幻觉（该查库的去聊天）、参数构造幻觉（工具选对了但参数错、字段名错、类型错）、以及过程性幻觉（声称做了实际没做的步骤，比如「我已经删除了」）。定位手段各不相同：事实性幻觉靠引用溯源（要求每个结论带出处，落地时校验出处真实存在），工具选择靠比对「应该调用的工具序列」与 Trace 里的实际序列，参数错误靠 schema 校验与执行期报错统计，过程性幻觉靠「只信工具返回值不信模型自述」的原则——这一点最好在架构上强制，比如最终答案里的可执行结论必须由代码从工具结果里拼装。三类手段里最有效的是确定性校验，因为它不依赖模型的自省能力，成本也最低。常见的补充手段：结构化输出（JSON Schema/函数调用约束格式）、检索前置（先给证据再让它答）、以及「自检一轮」的反思式校验，但后者对事实性幻觉收益有限，对格式与遗漏类问题更有效。

高风险操作的越权防护与兜底责任。 核心思路是把「模型可以提议、代码负责执行」做成硬边界：模型只产出结构化的操作意图，实际执行必须经过一层确定性程序做校验——参数合法性（范围、类型、必填）、业务约束（金额上限、频率上限、对象归属）、以及权限判定（这个用户在这个租户下有没有这个动作的权限）。校验不通过的调用不进执行器，直接以结构化错误回给模型让它修正或终止。兜底责任应该在代码侧：模型的判断永远只是「建议」，凡是涉及资金、删除、外发、权限变更的动作都要有确定性闸门和可审计记录，并且默认设计成「不确定就不执行」。这也回答「谁来兜底」：不是靠更强的模型，而是靠更窄的能力面——能做的动作越少、参数越受限，越权的空间就越小。

RAG 优化与图编排框架的坑。 RAG 的优化按收益排序大致是：分块策略与元数据（按语义结构切、带标题路径与时间戳，检索时能按版本过滤）优先于换模型，因为多数坏例来自切错和过滤缺失；其次是混合检索（向量 + BM25）与重排模型，前者补关键词精确匹配，后者把 top-k 的精度拉起来；再是查询改写与多路召回，最后才是嵌入模型升级。常见坑还有上下文塞太满导致关键信息被淹没（应该少而准，宁缺毋滥）、以及文档更新后索引未同步导致答旧内容。用 LangChain 这类框架容易踩的坑：抽象层泄漏（想调用的底层参数被封装掉，只能改源码或绕过）、版本升级破坏性变更、调试时链路被隐藏（一次调用背后几十层封装，排查只能靠 Trace）、以及 LCEL 语法糖写出来的链难以做条件分支和循环。我的判断是：原型期用框架换速度，生产期把关键链路（检索、工具调用、循环控制）改成显式代码，框架只保留非关键部分，可读性与可排查性远比「少写几百行」重要。

评测框架怎么做到可信。 框架的可信度来自三件事：判据可执行、样本可复现、结论可归因。判据尽量下沉成确定性断言（工具调用序列是否符合预期、参数是否合法、输出是否符合 schema、引用是否存在、耗时与成本是否超阈），只有语义质量这类无法判定的才交给模型评审或人工。样本要带上完整输入、期望与来源，并固定随机性（温度、种子、模型版本），否则同一套用例跑两次结果不同就无法比较。模型评审必须做偏差控制：换不同厂商的模型评、随机交换候选顺序消除位置偏见、禁用长度偏好、并要求给出逐条理由方便抽查；同时用一批人工标注做「评审模型与人的一致率」校准，一致率低的维度就不能拿来自动打分。人工评测的一致性靠标准先行：先写评分细则（每个维度的定义与分值锚点）、抽样对齐（多人评同一批、算一致性并讨论分歧）、必要时引入仲裁。评测框架最终要能回答「这次改动让什么变好、什么变差」，所以每次跑批要留存版本化的报告与回归基线，低分用例要能一键回填成回归样本。

状态、重试熔断与长任务防漂移。 状态管理的关键是分清三类：会话消息（可压缩）、外部化的任务状态（必须结构化、可持久化、可恢复）、以及大产物（放对象存储，状态里只存引用）。工具调度要稳定，靠的是统一入口：所有工具走同一个注册与执行通道，schema 统一校验、超时统一设置、重试策略统一声明（哪些幂等可重试、哪些只能补偿），这样不会出现某个工具自带重试把写操作执行两遍的情况。重试要限定在可重试错误类型上（网络超时、限流），用指数退避加抖动，并设最大次数；熔断按「下游/工具」维度统计滑动窗口失败率，超过阈值快速失败并进入半开探测，阈值不要拍脑袋定——先看正常流量下的错误率分布，取明显离群的水平。长任务漂移的处理前面说过，重点是每轮重新注入目标与判据、按阶段做 checkpoint 与压缩、关键结论只信工具返回。被追问「你遇到过吗」时，如实讲一个具体的（比如多轮后模型开始重复早期已废弃的方案，或摘要压缩把约束丢了），比泛泛而谈更有说服力。

多 Agent 协作的可验证性与成本控制。 多 Agent 的价值在于把上下文和职责切开，代价是通信失真与成本翻倍，所以协议设计是重点。避免自然语言不确定性的做法：角色之间传结构化消息（JSON/Protobuf），字段包括任务 id、状态、产物引用、证据、以及明确的 schema 版本；产出物一律落文件或存储，消息只带引用与摘要，避免长文本在 Agent 间反复转述而累积失真；跨 Agent 的约束用机器可校验的形式表达（谁可以调用谁、产物必须通过哪几项校验），而不是写在提示词里祈求遵守。可验证性则要求每个环节都有判据：子任务完成要过校验器，聚合结果要能回溯到上游证据，最终产物最好由确定性代码按模板拼装，模型只负责填写内容字段。成本控制的具体策略：按任务难度路由模型（简单步骤用小模型，规划与验收用大模型）、缓存检索与嵌入结果、限制工具返回体积（分页、字段裁剪）、控制上下文里保留的轮次、给每个任务设 token/时长预算并在超限时降级或终止。算账要说清口径：单位任务的 token 与费用、对照的基线版本、省钱来自哪一项策略，别只丢一个「省了 30%」。

硬件场景的端云分工、降级与可观测性。 硬件场景与纯软件最大的区别是资源受限、链路里有真实时序约束、以及用户就在设备边上（体验差立刻被感知）。端云分工的判断依据是四条：延迟预算（需要几十毫秒内闭环的必须在端侧）、可用性（断网也要能用的核心功能放端侧）、隐私与数据量（原始音视频尽量不出端，只上传特征或摘要）、以及模型能力（需要大模型的复杂推理放云端）。典型的混合形态是端侧做唤醒、意图识别、简单指令与安全兜底，云端做复杂规划与生成，用「本地先响应、云端再精修」的方式掩盖网络延迟。弱网降级要设计成分级能力：先降非关键能力（推荐、富文本、长回答），再降交互形式（语音转文字指令、预设模板），最后保证最小可用集（本地控制、离线缓存的历史会话）；要避免的是「网络不好就转圈」，用户需要明确的状态反馈和本地可完成的替代路径。可观测性上，Trace 至少要串起会话 id、每轮请求与响应、工具调用与耗时、端侧上行的时延分段（设备→云、云内处理、云→设备）、以及错误码与降级标记；关键指标看首字延迟、端到端成功率、降级触发率、以及各环节 P95/P99。线上排查的顺序是「先看影响面（多少用户、是否集中在某机型/固件/区域）→ 再看链路分段定位是端、网、还是云 → 然后看该版本的变更与依赖状态」，这套顺序能避免一上来就怀疑模型。