懂车帝 AI Agent开发一面

1. 讲一下你做过的一个 Agent 项目，重点说业务背景、流程和你负责的部分

2. 如果你的系统里也有高并发场景，你会怎么设计限流、降级和幂等

高并发下最怕的不是平均请求慢，而是少数慢请求把整条链路拖死。Agent 系统一般调用链长，请求里既有模型推理，也有工具 I/O 和数据库操作，所以不能只靠一个网关限流就完事。我会把限流拆成几层：入口做用户级和租户级限流，任务编排层做任务队列隔离，工具层做并发池控制，模型层再做 token 预算和超时回收。这样某一个工具服务出问题时，不至于把整个系统打爆。

幂等也很关键，尤其是有写操作的时候。像发通知、写审批、更新状态、创建工单这种动作，必须给每次执行一个 request_id 或 task_id，重复执行时能识别并返回历史结果，而不是让 Agent 失控重试。否则模型一次超时重发，后面会造成重复写入。

def execute_once(task_id, action, store):
    if store.exists(task_id):
        return store.get(task_id)
    result = action()
    store.save(task_id, result)
    return result

3. 你怎么理解 Agent 项目的数据，和传统模型训练数据有什么不一样

Agent 项目的“数据”不只是训练样本，它更像一整套运行时资产。除了用户问题和标准答案，还包括工具描述、执行轨迹、观察结果、失败日志、人工修正记录、最终是否完成任务这些信息。传统训练里你更多关注输入输出配对，但在 Agent 场景里，真正有价值的是中间过程，因为你要知道模型为什么会选错工具、为什么会在某一步卡住、为什么会把上下文读偏。

所以如果让我做数据闭环，我不会只存最终问答，而是把每一步的 thought proxy、tool call、observation、state transition 都结构化记录下来。后面无论做离线评测、策略优化还是做坏例回放，都会比只有最终答案强很多。

4. 如果让你优化一个 Agent 系统，你通常先从哪里下手

我一般不会一上来就换模型或者改 prompt，而是先拆系统瓶颈。Agent 变慢或者效果差，原因通常有三类：规划问题、执行问题、观察问题。规划问题是路径选错了，本来两步能完成的任务走成了六步；执行问题是工具调用成本高、失败重试多；观察问题则是模型拿到的信息太噪或者太散，导致每一步都判断不准。先把这三类问题拆开，才能知道该优化哪一层。

如果是性能优化，我通常先看工具调用次数和上下文长度，因为这两项往往最直接决定时延和成本。如果是效果优化，我更关注错误是否集中在某一类状态转移上，比如从分析态进入执行态过早，或者在证据不足时没有追问用户。真正有效的优化通常不是单点提分，而是把错误链条砍短。

5. 如果系统里需要接前端页面，你会怎么考虑 React 这类前端框架的接入方式

前端接入不是简单做个聊天框。Agent 项目里前端最好能承载过程可视化、步骤确认、局部纠错和结果回放这些能力，否则用户只能看到“模型想了一会儿然后给答案”，一旦出错体验很差。像 React 这类框架比较适合做节点流展示、操作面板和实时状态更新，尤其是当 Agent 涉及多步骤执行时，用户其实很需要知道系统目前卡在哪一步、用了哪些工具、拿到了什么结果。

如果让我设计，我会让前端把消息层和任务层拆开。消息层负责自然语言交互，任务层负责展示计划、步骤状态、风险确认和最终产物。这样用户既可以像聊天一样使用，也可以像操作台一样介入。

6. 你了解哪些 Agent 架构，分别适合什么问题

常见的 Agent 架构大致可以分成几类：一种是单 Agent + Tools，适合任务边界比较清晰的场景，比如问答、数据查询、代码补全；一种是 Planner-Executor，把规划和执行拆开，适合任务链长、需要多步决策的场景；还有一种是多 Agent 协作，把不同角色分工，比如检索、分析、审阅、执行分别交给不同 Agent，这类更适合复杂任务，但也更难控。

我自己更偏向从任务复杂度选架构，而不是一上来就堆多 Agent。很多团队做 Agent 一上来就上多角色，其实业务还没复杂到那一步，结果系统调试成本陡增。只有当单 Agent 明显承担不了上下文负荷，或者不同子任务能力要求差异很大时，多 Agent 才真的值得做。