万类智生 AI Agent开发 二面

1. 项目拷打

2. Agent 和传统工作流到底有什么区别

传统工作流更像一个提前画好的流程图，路径基本固定，输入来了以后按节点顺序执行，比如分类、检索、总结、返回。它的优点是稳定、可控、好排查，比较适合业务规则明确的场景。Agent 的核心不是“多一步调用模型”，而是“具备动态决策能力”。它会根据任务目标、当前上下文和外部环境决定下一步做什么，比如先查知识库还是先问用户补信息，要不要调工具，要不要继续分解任务。实际落地里，纯 Agent 和纯工作流都不多，更多是混合架构。主链路用 workflow 保稳定，在复杂节点里再让 Agent 做决策，这样可控性和灵活性都会更好一些。

3. 你理解的 AI Agent 核心组成是什么

一个完整的 AI Agent 至少有四个核心部分。第一是大模型本身，负责理解用户意图、做推理和生成。第二是工具系统，让模型不仅能说，还能查、算、执行。第三是记忆系统，负责保留会话上下文、用户偏好、历史任务结果。第四是规划与执行机制，也就是遇到复杂任务时能不能拆步骤、逐步调用外部能力并根据返回结果继续决策。如果再工程化一点，还需要知识库、状态管理、权限系统、日志追踪、评测体系和降级兜底机制。很多所谓的 Agent 做不起来，不是模型不够强，而是外围工程能力太弱。

4. Function Calling 或 Tool Calling 是怎么实现的

Function Calling 本质上是让模型输出结构化调用意图，而不是直接输出自然语言。比如模型判断当前问题需要查天气，它就返回工具名和参数，服务端拿到之后去执行真实函数，再把结果回传给模型继续生成。这里的关键点不是“让模型会调工具”，而是“服务端必须把边界管死”。因为模型只负责提出调用意图，真正的执行权限、参数合法性、超时控制、重试策略都应该由系统来决定。否则模型一旦输出异常参数，或者被 prompt injection 影响去调高风险工具，问题会非常大。

tools = {
    "get_weather": lambda city: f"{city} 今日多云，25度"
}

tool_call = {
    "tool_name": "get_weather",
    "arguments": {"city": "北京"}
}

def dispatch(call):
    name = call["tool_name"]
    args = call["arguments"]
    if name not in tools:
        raise ValueError("非法工具")
    return tools[name](**args)

result = dispatch(tool_call)
print(result)

5. Tool Calling 时怎么防止模型乱调用工具

防乱调用主要靠系统约束，不是靠模型自觉。第一层是工具白名单，不允许模型调用未授权工具。第二层是参数 schema 校验，比如字段是否缺失、类型是否正确、范围是否合法。第三层是权限控制，高风险工具必须加人工确认或者二次校验。第四层是工具结果标准化，返回尽量是结构化数据，避免模型自由理解。如果要再稳一点，还会加调用次数上限、超时熔断、失败重试和审计日志。因为 Agent 一旦进入循环推理，如果没有这些约束，很容易出现重复调用、无效调用甚至死循环。

def validate_tool_call(call):
    allow = {"get_weather", "search_doc"}
    if call["tool_name"] not in allow:
        return False
    if call["tool_name"] == "get_weather":
        return "city" in call.get("arguments", {})
    return True

6. RAG 在 Agent 里面一般起什么作用

RAG 的作用是把模型参数外的知识补进来，让 Agent 的回答尽量建立在证据上，而不是靠记忆猜。对于企业场景来说，知识经常是动态变化的，比如产品文档、客服规则、内部 SOP、工单、运营策略，这些不可能完全靠模型参数记住，所以 Agent 往往要先检索，再生成。在 Agent 里，RAG 不只是“查一下知识库”，而是经常参与决策。比如模型先判断这个问题是否需要外部知识，如果需要，再决定检索什么、检索几轮、是否改写 query、是否 rerank，最后再基于召回内容组织答案。所以 Agent + RAG 的关键不只是“接了向量库”，而是检索、排序、生成、引用这几个环节如何闭环。

7. 如果 RAG 效果不好，你怎么判断问题出在检索还是生成

最常见的判断方法是拆链路。先看正确证据有没有被召回到，如果 top-k 里面根本没有目标内容，那就是召回问题。召回到了但排位很靠后，通常是排序问题。证据排在前面模型还是答错，就更像是生成阶段没用好上下文，或者 prompt 设计有问题。工程上通常会做 evidence 级评测，不只看最终答案对不对，还会看 gold evidence 是否命中、命中位置、引用是否正确。因为只看最终答案，很容易让检索和生成互相甩锅。如果线上问题比较多，我一般会把 query、召回结果、rerank 结果、最终 prompt 和模型输出全链路打到 trace 里，这样排查会快很多。

8. 多轮对话里的 Memory 一般怎么做

Memory 不能简单理解成“把历史消息全拼进去”。真正可用的记忆系统一般是分层的。最近几轮原始对话是短期记忆，用来保证当前上下文连贯；用户偏好、身份信息、常见需求属于长期记忆，通常结构化存储；很长的会话则做摘要记忆，把关键事实压缩下来。在实际系统里，最常见的做法是保留最近 N 轮原文，再把更早内容总结成摘要，同时把关键事实抽出来单独保存。等下次生成时，不是所有历史都放进去，而是根据当前问题按需召回相关记忆。这样既能控制上下文长度，也能提高真正有用信息的密度。

memory = {
    "recent_messages": [
        {"role": "user", "content": "帮我订明天去上海的机票"},
        {"role": "assistant", "content": "好的，请问从哪个城市出发？"}
    ],
    "