百度 Agent 后端三面：Agent 编排与动态知识库

《面试题目》

1. 团队做内部 AI 研发提效平台和动态知识库，知识来源是什么、在研发中怎么用、更新是定时还是触发式，关系库与向量库如何分工？
2. AI 如何自动保证知识质量、如何为代码任务加载精准知识、如何评测知识的实际采纳效果？
3. 你使用过 Milvus，请介绍它的架构；它维护的是文件、内容还是索引？
4. 介绍一下近期做过的 Agent、Skill 或相关技术方案。
5. 优化前后的耗时分别是多少？「端到端」的具体场景、起点和终点是什么？
6. 从 Plan/Action 切换到更轻量的方式后，AI 的计划和自愈能力是否受损？上下文处理是怎么做的？
7. 提速减少了哪些环节？优化后的稳定性如何，如何权衡效率与稳定性？
8. 原来的 Workflow 是什么样，后来为什么改成 Agent 和 Skill？
9. 是否考虑过串联多个 Skill，为每个环节设置质量准出标准，结果不达标时再执行或修正？
10. 如果多花约一分钟可把准确率提高 20 至 30 个百分点，如何设计质量与性能的权衡？谁对单个 Skill 和整合效果负责？
11. 反问环节：入职初期主要做 AI 研发提效平台还是动态知识库？动态知识方向大概从什么时候开始，其他团队是否也在做类似的自我迭代与自愈？AI 会参与代码自测吗，整个过程是自动化的吗？

《参考解析》

Milvus 的架构，以及它到底维护什么

Milvus 是存算分离的多组件分层系统。接入层是各语言 SDK 与 Proxy，对外提供 gRPC/REST，负责请求路由和结果合并；协调层原本是 RootCoord、DataCoord、QueryCoord、IndexCoord，2.2 之后合并为 MixCoord，管元数据、段（segment）分配、索引构建和查询调度；执行层是 QueryNode、DataNode、IndexNode，分别负责检索、日志消费入盘和建索引；存储层是 etcd（元数据与协调状态）、消息队列（Pulsar/Kafka，写路径的日志流）和对象存储（binlog、索引文件、删除日志）。所以它维护的既不是原始文件、也不是文件内容本身，而是向量与标量字段，以及围绕它们的分段和索引结构：新数据先落在 growing segment 就能被查到，落盘转为 sealed segment 后建索引；一致性级别（Strong / Bounded / Session / Eventually）决定你能读到多新的数据。答这题时顺带补一句边界会显得很懂：原始文件和原文存在业务侧的对象存储或文档库里，Milvus 只存切片后的文本和向量。

关系库与向量库怎么分工，知识怎么保持新鲜

关系库（或文档库）存权威的结构化元数据：来源、版本、生效与失效时间、权限范围、可信等级、负责人；向量库存切片和向量，并冗余一份过滤字段用于检索裁剪。检索链路应该是「先用时间、权限、标签等标量条件过滤，再做 ANN 召回」，而不是先按相似度取 Top-K 再过滤——后者很容易让过期或越权文档把有效结果挤出去。更新通常两条腿走路：代码仓库和文档系统的变更 webhook 做增量触发，再配一个定时全量对账兜底，防止漏事件导致长期不一致。质量治理要有可观测的指标：重复率、解析失败率、过期文档占比、人工抽检通过率；「让 AI 自动保证质量」落到工程上就是冲突检测、过期下线、引用可追溯，最后用采纳效果（生成的代码或测试是否被接受、被回滚的比例）反向验证。

Agent 与 Workflow 的取舍，以及轻量化之后的自愈

Workflow 的优点是路径确定、成本和延迟可预估、失败点好定位，适合步骤稳定的环节；Agent + Skill 换来的是动态编排和自愈能力，代价是延迟、Token 消耗和不确定性上升。从 Plan/Action 换成更轻量的方式（少一次规划、直接选工具）确实可能削弱全局规划：模型看不到整体依赖时更容易走偏，失败后也更难重新规划。补法是设「质量准出」——每个 Skill 声明输入输出契约、成功判据和重试上限，串联时逐环节校验，不达标就用更重的模式（重新规划或换工具）兜一次，而不是全程都走最贵的路径。上下文侧要主动裁剪：只保留任务相关的摘要和最近的工具结果，长历史外置成可检索的记忆，避免每轮把全部轨迹重放一遍。

多花一分钟换 20 到 30 个百分点准确率，怎么设计

先分清哪条是热路径。内部研发提效平台的用户能接受分钟级等待，但等待必须可预期，所以做法通常是分级：默认走快路径，命中「低置信、高风险、涉及代码改动」这些条件时升级到慢路径，并把升级原因和预期耗时回报给用户。接着算账：多一分钟换 20 到 30 个百分点准确率，只要省下的人工时间远大于一分钟就划算，但要用采样评估，避免把个别样本的提升当成普遍收益。责任划分上，单个 Skill 由它的 owner 对质量准出标准和评测集负责，端到端效果（任务完成率、平均耗时、人工介入率）由平台侧统一负责并定期回归，否则很容易出现每个 Skill 都达标、串起来却不可用的情况。

反问环节的提问质量

入职初期做提效平台还是动态知识库、这个方向从什么时候开始、有没有别的团队在做类似的自我迭代、AI 是否参与代码自测——这些问题都落在「我进来具体干什么、这个方向是不是真在投入」上，比问福利和加班更有信息量。三面通常由主管或跨级面试官进行，问这类问题也顺便展示了对业务的理解。