快手 大模型开发 二面

1、自我介绍

2、实习中搭建智能体是为了解决什么样子的问题

3、搭建的过程中，你是怎么设计的

我在设计智能体的时候，不会把它做成一个完全自由发挥的黑盒，而是尽量让它处于“有限自主”的状态。整体上我会拆成几个模块：输入理解、任务规划、工具路由、执行器、状态管理和结果汇总。输入理解负责把用户请求转换成更清晰的任务表示；任务规划决定当前问题要不要拆步骤，以及每一步的执行顺序；工具路由负责选择检索、分类、规则引擎或者外部接口；执行器负责真正调用；状态管理负责记录中间过程，避免模型每次都只靠上下文硬记；最后再由汇总模块把过程结果整理成最终输出。

设计时我比较看重两个点。一个是工具边界要清楚，不能让模型既决定任务又随意拼参数，否则线上最容易出错。另一个是状态必须尽量结构化，尤其是多轮任务或者多步骤推理时，不能把所有中间信息都堆在自然语言里，否则越到后面噪声越大。实际落地时，智能体不是越自由越好，而是越可控越容易稳定。

4、链路搭建是一次性成功的吗，衡量过准确率吗

肯定不是一次性成功的。智能体这种链路最开始一般都能跑通，但“跑通”和“可用”差别很大。第一版往往只是在少量样本上看起来没问题，真正放到更复杂的输入里，就会暴露出很多问题，比如任务拆解不稳定、工具选错、参数抽取有偏差、上下文污染、结果整合失真，这些都很常见。

准确率是一定衡量过的，但不能只看单一指标。因为智能体不是一个纯分类器，它的问题可能出在多个环节。所以我会把评估拆开看。先看任务识别是否正确，再看工具调用是否正确，再看最终结果是不是符合预期。如果是审核或者识别类场景，还会看准确率、召回率、误杀率、漏检率这些指标；如果是多步骤任务，还会额外看链路成功率、单步执行成功率和整体完成率。很多时候最终效果不好，不一定是模型本身弱，而是前面某一步把错误放大了，所以评估必须分层做。

5、你怎么做智能体效果评估，除了准确率还看什么

智能体效果评估如果只看最终准确率，其实信息量是不够的。因为一个结果答对了，不代表中间过程合理；一个结果答错了，也不一定能直接定位到是哪一步出了问题。所以我一般会把评估拆成结果评估、过程评估和系统评估三层。

结果评估关注任务是否完成、输出是否符合业务要求。过程评估关注规划是否合理、工具是否选对、参数是否正确、是否发生了无效循环或者多余步骤。系统评估则会看延迟、成本、超时率、重试率、失败样本分布这些工程指标。对真正的业务系统来说，最终能不能稳定上线，很多时候不是由单次回答质量决定的，而是由整体链路稳定性决定的。

6、如果智能体在同一个问题上多次执行结果不一致，你怎么解决

这个问题本质上是智能体稳定性问题。它出现的原因通常有几类。第一类是模型本身采样带来的波动，比如 temperature 偏高或者规划阶段太开放；第二类是 Prompt 定义不够清晰，导致模型对任务边界理解不一致；第三类是上下文状态不稳定，历史 observation 的组织方式不同会影响后续决策；第四类是外部工具返回本身就不稳定。

解决思路一般是先减少不必要的自由度。比如在规划阶段把 Prompt 写得更明确，限制输出结构；降低生成随机性；把高频稳定场景固化成半工作流，不让模型每次都自由拆解。对于关键工具调用，还可以加显式约束和后验校验。再往上一层，如果发现某类问题天然就容易发散，那就不能强行让智能体全自动决策，而是要加规则兜底或者人工确认点。很多智能体问题的本质不是“模型不聪明”，而是系统没有把不确定性收住。

7、提示词你是怎么设计的，怎么让模型更理解业务意图

Prompt 设计本质上是在做任务表达和边界约束。让模型理解业务意图，不是靠把提示词写得很长，而是靠把目标、标准、上下文和输出形式讲清楚。我一般会先明确角色，比如它现在是审核助手、识别助手还是任务规划器；然后写清楚当前任务目标，再把判断标准、禁止行为、输出格式单独列出来。如果业务场景边界复杂，我还会加入正反例，让模型更清楚什么该判、什么不该判。

在真实业务里，提示词不能只追求“看起来完整”，而是要尽量减少歧义。尤其是审核、识别、分类这类场景，模糊表述非常容易导致模型漂移。