CVTE AI Agent开发 二面

1、自我介绍

2、如果让你设计一个可回放、可调试、可审计的 Agent Runtime，你会怎么做

一个真正能在线上稳定运行的 Agent Runtime，不应该只是“模型 + 工具调用”这么简单，而应该是一个有状态机、有事件日志、有回放能力的执行系统。我会把它拆成几个核心模块：任务上下文、Planner、Executor、Tool Adapter、State Store、Event Log、Policy Engine 和 Replay Engine。

任务执行时，不是把所有中间过程都放在 Prompt 里，而是把关键状态结构化存储。比如当前步骤、已完成动作、失败次数、工具返回摘要、等待确认事项、上下文版本号，这些都应该进状态仓库。每一步执行都记录事件日志，日志至少包括时间戳、输入、模型输出、工具参数、工具结果、状态快照和错误信息。这样出了问题后，不只是能看最终答复，而是能完整重放执行链路。

Replay Engine 的作用非常大。它不仅能帮助排查线上问题，还能把失败样本变成评测集。很多 Agent 系统做不稳，不是模型差，而是没有执行轨迹，出了问题只能猜。可回放和可审计，决定了这个系统能不能真正走向工程化。

3、如果 Agent 使用工具时经常出现“参数看起来对，语义其实错”的问题，你怎么处理

因为 schema 校验只能保证字段存在、类型正确，但不能保证语义正确。比如查询时间范围填了，但时间窗口不符合用户意图；地点字段合法，但不是目标城市；筛选条件存在，但约束方向反了。

处理这种问题，我会做三层控制。第一层是工具定义层，把参数说明写成接近判定规则的形式，而不是一句很短的描述。必要时给参数加正反例。第二层是执行前语义校验，不只是校验类型，还要校验参数之间的关系，比如开始时间不能晚于结束时间、筛选条件是否互斥、是否缺少业务上必需的上下文。第三层是执行后结果一致性验证，也就是拿工具结果反向检查是否符合用户目标。如果查到的内容和问题明显不一致，就不能直接进入下一步，而应该触发重试、澄清或者回退。

很多团队把工具调用不稳定理解成“模型不会填 JSON”，其实更难的是语义一致性。真正解决这个问题，不能只靠 Prompt，要有程序级约束和结果校验。

4、如果 RAG 召回没问题，但生成阶段经常“引用错证据”或者“把多段证据拼坏了”，你怎么优化

这种情况说明问题不在召回，而在证据组织和答案约束。模型虽然拿到了相关片段，但没能正确使用。常见原因有几个：上下文太长、证据冲突、片段顺序混乱、引用边界不清、Prompt 没有要求逐条归因。

我一般会先调整 evidence packing 的方式。不是简单把 topk 全拼进去，而是按主题聚类、按时间排序或者按规则优先级重排，让模型看到的是“可推理的证据结构”，而不是“证据堆”。第二步是把生成任务拆成两阶段，先做证据选择和归因，再做最终生成。比如先让模型输出“结论对应哪些证据片段”，通过后再拼成自然语言答案。第三步是对答案做 attribution check，检查输出中的每个关键结论是否都能映射回检索片段。不能映射的部分要么删除，要么标记不确定。

如果业务很严肃，我甚至会把“自由生成答案”改成“基于证据填模板”。因为很多时候用户想要的是准，而不是文采。生成系统最危险的地方，就是它把部分正确证据和部分错误推断混在一起，看起来像真的。

5、MoE 模型在线推理时，为什么有时候吞吐没上去，反而更差

很多人觉得 MoE 参数大、激活少，所以推理一定更省，但线上不一定。MoE 的理论优势是每个 token 只经过少数 expert，计算量不会随着总参数线性增加。但工程上它会带来新的瓶颈，尤其是路由不均衡、跨卡通信和 batch 内 token 分布离散。

如果 expert 分配不均匀，有些 expert 很忙，有些 expert 很闲，就会出现负载倾斜，导致整体等待最慢 expert。其次，MoE 在多卡环境下往往需要 token dispatch 和 gather，这个过程通信代价很高，尤其是 batch 小、请求碎片化或者并发不稳定时，通信开销可能直接吃掉计算收益。再加上线上请求不是训练那种规整 batch，真实流量的长度、领域和输入差异会让路由模式更不稳定。

所以 MoE 在线上想把吞吐做起来，不能只看理论 FLOPs，要看 expert placement、通信拓扑、batch 聚合能力和调度策略。很多时候，小而稳的 dense 模型在真实业务里反而更容易把 SLA 做好。

6、如果长上下文下模型开始出现“中间遗忘”，你会怎么验证它到底是不是注意力退化

要验证是不是注意力退化，不能只凭感觉说“长文本效果差了”。我会先做受控实验，把问题拆成不同位置的信息依赖任务，比如答案只依赖前部、中部、后部、跨段组合这几类。然后构造长度逐渐增加的数据，观察模型在不同位置上的命中率变化。

如果发现前后信息还行，中间信息明显掉得快，这通常就是典型的 lost-in-the-middle 问题。再进一步，可以看 attention pattern、检索片段被引用的分布、答案中对中间证据的使用率。如果业务里有日志，还能对比模型到底有没有“看见”那段信息，比如在 reasoning trace 或中间选择步骤里是否提到了关键证据。

解决时，一般不是单靠把窗口继续拉长，而是要结合重排、摘要、关键片段前置、多轮检索或者 query-focused packing。长上下文的核心不是“装得下”，而是“拿得准”。

7、如果让你做一个支持千级并发会话的流式 Agent 服务，链路上最容易炸的点是什么

最容易炸的通常不是单个模型推理，而是长连接、状态管理和下游依赖叠加之后的资源耗尽。流式 Agent 服务通常要维持大量 SSE 或 WebSocket 连接，这会长期占用连接资源、协程资源和缓冲区。再加上 Agent 一次请求不一定只调一次模型，可能还会穿插检索、工具调用、数据库、外部 API，这时候真正的瓶颈往往变成全链路排队。

具体来说，几个高风险点很常见。第一是流式输出期间客户端消费慢，导致服务端发送缓冲堆积。第二是 Agent 链路较长，一个请求占着连接很久，吞吐上不去。第三是工具超时拖住整个会话，造成协程堆积。第四是上下文和 KV Cache 导致显存与内存同时紧张。第五是日志打点太重，高并发下 I/O 成为隐藏瓶颈。

解决这类问题，不能只优化模型。要同时做会话级超时、背压控制、异步任务拆分、工具熔断、请求队列治理、连接资源回收和分层缓存。流式服务的难点从来都不是“能流出来”，而是“高并发时还能稳定地流”。

8、你怎么设计 Agent 的幂等性和重试机制，避免同一个动作被执行两次

这在真实系统里非常关键，尤其是 Agent 一旦开始执行副作用操作，比如发消息、下单、写数据库、调用第三方接口，多执行一次就可能出事故。幂等性的核心不是“重试要小心”，而是从设计上给每个动作明确唯一身份和可验证结果。

我的做法通常是这样：每个执行动作都会生成 action_id，并绑定任务 id、步骤 id、参数哈希和时间戳。执行器在真正调用工具前，先查这个 action_id 是否已经成功提交。如果已经执行成功，就直接返回已有结果，而不是重复调用。对于不可逆操作，必须支持 pre-check 和 post-check，比如执行前先确认当前状态是否已满足目标，执行后再验证是否真的成功写入。

重试机制也不能是无脑 retry。要区分错误类型：超时、网络抖动可以重试；参数错误、权限