百度 Agent 二面：不看简历、不做自我介绍，连抛 6 道架构题

《面试题目》

1. 解释什么是 Agent 应用？
2. 一个面向 C 端的 Agent 应用包含哪些架构和模块？
3. Agent 和普通 AI 应用有什么区别？
4. 如果让你设计一个通用 Agent Runtime，要兼容 OpenAI、Anthropic、国产模型等多个厂商 API，怎么设计？怎么抽象？
5. Agent 在 C 端大规模部署时 Token 成本很高，怎么控制成本？有哪些具体的优化策略？
6. 如果 Agent 需要生成代码并在沙箱里执行，怎么设计安全沙箱环境？有哪些必须考虑的安全风险？
7. Agent 上下文越来越长，快超过 Context Window 时一般怎么处理？如果让你设计上下文压缩方案，怎么保证不丢关键信息？
8. 当前 Agent 系统最大的工程挑战是什么？是上下文管理？工具调用可靠性？成本控制？评测体系？还是别的？如果有无限资源，你会优先解决哪个问题？
9. 如何理解 Prompt Engineering → Context Engineering → Harness Engineering 的演进？三者有什么区别？
10. Agent 应用怎么做评测？评测集怎么构建？人工评测和自动评测怎么结合？
11. Agent 效果不好，怎么归因？是模型问题、检索问题、工具问题还是规划问题？怎么判断性能瓶颈来自模型、检索还是工具调用？
12. Agent 系统可观测性怎么做？Trace 怎么设计？分几层？用户一次请求在 Trace 上是什么形式？
13. Trace 怎么用？会做分析吗？有没有通过 Trace 分析过中间问题？
14. Agent 怎么做监控和告警？关注哪些指标？告警阈值怎么设置？
15. Agent 服务挂了怎么保证用户无感知？有没有做熔断？
16. 多 Agent 协作时，Agent 之间怎么通信？用过消息队列吗？
17. 手撕：判断二叉树是否平衡。后序遍历返回子树高度，若任一子树不平衡返回 -1。

项目追问

18. 你最近做的最复杂的 Agent 项目是什么？共享屏幕讲核心代码模块。
19. 调度层 Planner/Executor 怎么实现？为什么用异步不用同步？
20. 异步任务状态怎么持久化？

《参考解析》

1. 什么是 Agent 应用，它和普通 AI 应用的分界。 普通 AI 应用是一次输入一次输出的映射；Agent 应用自己在循环里推进任务：有目标，能感知环境（读文件、查库、看接口返回），能调用工具改变外部状态，把观察结果带回上下文再决定下一步，并在满足条件时停下。判据是三条：目标驱动的多步循环、工具与环境交互、跨步骤状态。落地几乎都是受控 Agent，外层由代码定义状态机、预算与终止条件，内层把某一步的判断交给模型。C 端 Agent 按接入、编排、能力、数据、治理五层切：接入管渠道、鉴权与限流；编排管上下文组装、规划、路由、工具循环与降级；能力层是模型网关与工具网关；数据层存会话、事件日志、索引与画像；治理层是评测、Trace、成本与安全。真正拉开差距的往往是治理层。

2. 通用 Agent Runtime 的多厂商抽象。 定义一层内部协议、把差异挡在适配器里：消息模型（role、文本与图片分块、工具结果单独成消息）、工具描述（统一 JSON Schema，适配器再转各家 function calling）、生成参数（温度、最大 token、思考等级、结构化输出）、流式事件（文本增量、工具调用增量、结束原因、用量）。适配器负责请求改写、能力降级（不支持原生工具调用就用提示词模拟加解析重试）、错误与配额治理（区分限流、5xx、参数错的语义，做退避与跨厂商切换）。Runtime 还要提供与模型无关的横切能力：上下文预算、重试与幂等、并发限流、结构化输出校验、成本记账、Trace 埋点。一条纪律是模型名与思考等级只在路由配置里出现，业务代码不写死，否则换模型等于全仓搜索替换。

3. C 端 Token 成本控制。 按输入、输出、次数、单价四轴拆。输入侧：分层记忆只带相关历史、工具结果先裁剪再入上下文、大文档只放命中片段、用 prompt caching 复用前缀、按意图筛候选工具而不是全量 schema。输出侧：限制 max_tokens、要求结构化短输出、长文生成只在必要时做。次数侧：明确终止条件、去重已执行的工具调用、缓存纯读且幂等的结果、能规则解决的不调模型。单价侧：按任务难度路由模型与思考等级，简单任务走小模型或规则。优化必须有记账与归因，并且看单次任务总成本而不是单次调用成本——压得太狠导致重试与追问变多反而更贵。

4. 代码执行沙箱与上下文截断的坑。 沙箱的风险是任意命令执行与提权、读宿主机与内网资源、资源耗尽、数据外传。设计按最小权限、强隔离、可观测来：独立内核（microVM 或 gVisor）而不是只用 namespace；根文件系统只读、可写区用临时 overlay 用后销毁；不挂宿主目录、不暴露 docker.sock；非 root 并去掉全部 capability；seccomp 白名单；cgroup 限 CPU、内存、PID、IO 与时长；网络默认断开或走白名单代理，禁止内网网段与云元数据地址。上下文截断的坑是结构性的：硬截会破坏 tool_call 与工具结果的配对，很多厂商 API 直接报错；也会删掉“已做过某步”的记录导致模型重复调用同一工具。所以要按结构裁，成对删除、优先丢最早的完整轮次、系统提示与当前任务约束永不裁，并把关键状态外置到文件或状态表。

5. 上下文压缩与 Prompt、Context、Harness Engineering 的演进。 压缩的正确形态是状态外置加分层：结构化任务状态（目标、硬约束、已完成、待办、关键实体与证据位置）由代码维护且不参与压缩；近期若干轮保留原文；更早的做摘要；工具大结果只留摘要与引用。压缩提示要写成有输出契约的抽取任务，压缩后做实体与数字的一致性校验，丢了就从原文回捞——压缩只替换注入内容、不删原始记录，避免多轮压缩累积漂移。三层演进的关系是：Prompt Engineering 优化单条提示的措辞与格式；Context Engineering 扩大视野到这一次模型能看到什么，关注检索、记忆、工具返回、顺序与预算；Harness Engineering 再往外一层，把模型放进可运行的系统——循环与状态机、工具与沙箱、权限与审批、重试降级、评测回归、Trace 与成本、多模型路由。核心是让模型不可靠的部分由代码兜住：判断交给模型，确定性步骤交给代码。

6. 评测、归因、Trace、监控与多 Agent 通信。 评测要分层：检索看 Recall@k 与 MRR，工具看成功率与参数正确率，规划看无效步数与错分支比例，生成看正确性与幻觉率，最后是端到端任务成功率与追问率；评测集靠真实日志分层采样加难例与对抗样本，自动判据与 LLM 判官结合且判官要与人工标注校准。归因用 Trace 逐层排除：换更好的上下文看是不是模型能力问题、核检索是否召回证据、核工具是否成功、最后看规划与路由是否走错；延迟用分解判断是容量还是单点慢。Trace 按请求、轮次、步骤三层，用户一次请求在 Trace 上是一棵按时间排序的树，展开能看到每一步的状态与错误。监控四类指标：可用性、性能（首 token 时间与 P95 延迟）、成本、质量（工具成功率、重试率、点踩率），阈值用历史分位数设；熔断用滑动窗口，降级手段是多厂商切换、换小模型、关非关键工具、返回缓存兜底，并给用户明确可继续的反馈。多 Agent 通信按耦合度选：共享工作区最松，消息传递（队列或 MQ）最常用但要做幂等与超时，共享内存只适合同机强协作；最稳的是控制面走消息、数据面走共享存储只传引用。判断二叉树是否平衡用后序遍历返回子树高度，用 -1 表示已不平衡，任一子树不平衡就直接返回，空节点高度为 0，O(n) 时间、O(h) 空间。