滴滴 AI Agent开发二面

1. 自我介绍

2. 项目拷打

3. 如果让你从 0 到 1 设计一个生产级 AI Agent 系统，核心架构怎么拆？

生产级 AI Agent 系统一般拆成接入层、编排层、模型层、记忆层、工具层、知识层、状态层、观测层和安全层。

接入层负责用户请求接入、鉴权、限流和会话管理。编排层负责意图识别、任务拆解、路由不同执行链路。模型层负责推理、规划、总结和结构化输出。记忆层负责短期会话记忆和长期用户记忆。工具层负责调用搜索、数据库、工单、日志、订单、风控等外部系统。知识层负责 RAG 检索、重排、知识库版本管理和权限隔离。状态层负责维护任务状态机、步骤执行记录、幂等控制和失败恢复。观测层负责 tracing、日志、指标、告警和成本统计。安全层负责 Prompt Injection 防护、权限校验、敏感操作审批和输出审计。

真正难点不在于让模型“能答”，而在于让系统“可控、可恢复、可追踪、可灰度、可降级”。

4. Agent 的 planning 和 workflow 编排有什么本质区别？

Planning 是让模型在运行时根据目标动态决定下一步做什么，本质是运行时决策。Workflow 编排是提前把流程设计好，模型只在固定节点里做局部判断，本质是预定义控制流。

Planning 的优点是灵活，适合开放任务、复杂推理和未知路径问题。缺点是不可控、稳定性差、调试难、成本高。Workflow 的优点是稳定、可观测、便于回放和治理，缺点是灵活性有限。

线上大部分系统不会纯 Planning，也不会纯 Workflow，通常是“Workflow 为骨架，Planning 为局部能力”。也就是主流程由系统控制，只有在检索、工具选择、参数补全、候选方案生成这些局部环节交给模型决策。

5. ReAct、Plan-and-Execute、Reflection 三种 Agent 范式有什么区别？

ReAct 的核心是边思考边行动，一步推理一步调用工具，适合短链路任务。优点是实现简单，缺点是容易局部最优、路径抖动明显。

Plan-and-Execute 的核心是先生成整体计划，再按步骤执行。优点是全局性更强，适合复杂任务，缺点是初始计划如果错了，后面会整体偏掉。

Reflection 的核心是让模型对当前结果做自检、自我修正或者多轮复盘。优点是能提升复杂任务正确率，缺点是延迟和 token 成本明显增加，而且并不保证一定修正成功。

生产环境中，通常会把 Reflection 限制在高价值任务或者失败重试分支里，而不是每个请求都开。

6. 多轮 Agent 任务里，状态机应该怎么设计？

状态机一般至少包含 created、running、waiting_tool、waiting_user、retrying、failed、finished、cancelled 这些状态。每一步执行都需要记录 step_id、动作类型、输入、输出、耗时、重试次数和错误原因。

状态机存在的意义是把“模型说了什么”和“系统当前处于什么阶段”分开。模型只是建议下一步，真正的状态推进必须由执行层决定。否则一旦模型输出漂移，多轮任务就会失控。

如果涉及外部动作，比如发消息、建工单、退款、调度任务，还要给每个动作绑定 operation_id，避免重试时重复执行。

7. Agent 为什么一定要做幂等？怎么做？

因为 Agent 不是只生成文本，它会执行真实动作。网络重试、超时补偿、模型重复规划、消息重复投递，都可能导致同一个动作被执行多次。如果没有幂等，后果可能是重复下单、重复建单、重复通知、重复退款。

常见做法是给每个可执行动作生成唯一幂等键，例如 request_id、task_id、operation_id，服务端先查幂等表，如果已经执行过，直接返回历史结果；如果没执行过，再进入真实执行逻辑。

class IdempotentExecutor:
    def __init__(self):
        self.store = {}

    def execute(self, op_id, fn, *args, **kwargs):
        if op_id in self.store:
            return self.store[op_id]
        result = fn(*args, **kwargs)
        self.store[op_id] = result
        return result

8. 如果 Agent 调用了多个工具，如何保证事务一致性？

严格意义上的分布式事务在 Agent 这种跨系统场景里很难做，工程上更常见的是 Saga 思路，也就是每个正向动作都设计对应补偿动作。比如先创建工单、再发通知、再更新状态，如果中间失败，就按逆序做补偿。

另一种思路是把强一致要求限制在核心系统内部，Agent 只负责编排，不直接承诺跨系统原子性。对于真正关键的动作，通常采用“审批 + 状态落库 + 异步执行 + 补偿恢复”的方式，而不是让模型串行同步执行到底。

关键点不是“保证绝对不出错”，而是“出错后能知道错在哪、能否补偿、是否可恢复”。

9. 如果线上 Agent 延迟突然升高，你怎么定位瓶颈？

先拆分整体耗时。一般把一次请求拆成意图识别耗时、检索耗时、重排耗时、模型首 token 耗时、模型全量生成耗时、工具调用耗时、序列化和网络传输耗时。

如果是模型问题，要看排队时间、GPU 利用率、batch 策略、KV Cache 命中、上下文长度和输出长度。如果是检索问题，要看向量库查询耗时、索引配置、数据规模和冷热点分布。如果是工具问题，要看下游接口 RT、超时率和重试比例。如果是链路问题，要看是否存在串行调用过多、无效 Reflection、冗余检索或者 Prompt 过长。

排查顺序一般是 tracing 先定位大头，再针对大头做 profile，不要上来就猜模型慢。