已入职携程Agent开发岗45K，面试很水不用焦虑

上个月，我带的一个学员正式入职携程的 Agent 开发岗，45K。

他原来 28K，七年 Java 后端，在一家做旅游 SaaS 的中厂做供应商对接和库存同步——航司接口、酒店直连、价格库存那套。这两年带过的学员里，他不是底子最好的，但是对"真实世界的脏"最有体感的一个。今天把他这一路掰开讲，想转的可以照着对一下。

先说大家最关心的：面试难不难。

我的原话是——比他想象中水多了。但这个"水"有前提，而且不太好听：他在职折腾了半年，中间有两个月做的东西，被我一句话否了大半。

所以先把话放这儿：45K 是他的结果，不是你的时间表。"水"指的是考察点特别集中，不是不用准备。为什么水，看到最后你就明白。

他的底子，和一份没有目录的说明书

七年 Java，中厂，供应商对接方向。说白了就是接外部接口、做库存同步、处理超时和对不齐的账。

去年公司要做一个行程助手项目，抽人支援，没人愿意去——老系统要维护，新东西没 KPI。他手上刚做完一轮供应商对账，空出来了，报了名。干了两个月，他发现这东西跟写对接逻辑完全是两套思路，外面这类岗位开价还高一大截。

然后他来找我，第一句是：

"老师，我是不是得先把多智能体那套框架啃下来？"

我说不用。你写了七年 Java，框架从来不是门槛。 你的问题不是不够懂 AI，是你还在按"一个确定的世界"来设计 Agent——而 OTA 这个行业，唯一确定的就是它随时在变。

这话他当时没听懂，后面吃了亏才明白。

他先自己干了两个月：做了三十多个工具——查航班、查酒店、查订单、查退改签政策、查优惠券——然后全塞进 prompt，让模型自己选。

我说你这不是在给模型能力，你是在给它一份没有目录的说明书。

他自己也感觉到了：工具一多，模型开始乱选，明明该查订单里的航班，它去查了航班时刻表；prompt 越来越长，token 和延迟一起往上走；最麻烦的是每加一个工具，前面调好的场景就可能退化。

模型不怕没有工具，怕的是工具太多，而且没有一个它分得清。

从那天起他的主战场变了：不是"再做十个工具"，是"怎么让它在这堆工具里选对"。

第一步：先承认日期是算不准的（2 周）

先把模型当一个会抽风的第三方接口玩熟——不是"会用"，是玩熟。

我让他做的动作很具体：给一段用户的口语化需求，让模型抽出结构化查询条件——目的地、日期区间、人数、预算、偏好。

第一版他就被上了一课。用户说"下周三出发，玩个三天左右"，模型直接抽出了绝对日期。看着没问题，其实三个坑：今天是哪天模型不知道；"下周三"含不含这一周，各人理解不一样；"三天左右"算三天还是四天，它每次给的答案还不一样。

这一类东西，模型算不准，而且它不知道自己算不准。

后来改成：日期、人数、金额这类 确定性计算全部交给代码 ——模型只负责识别出"下周三""三天左右"这几个原始片段，归一化和换算走规则函数，算完再回填给模型。

验收线定得很死：抽出来的绝对日期必须能追溯到原始文本里那几个字，对不上就走澄清。外加一句： 能用代码算的，别让模型算。

这句话，后面在他整个项目里反复出现。

第二步：规则是活的，你的知识库也得是活的（4 周）

OTA 最要命的一块是退改签政策。

特点是：各家不一样、同一家也经常变、变了之后旧的立刻作废。他一开始走的还是 RAG 老路——把政策文档切了建索引。

跑出来发现一个致命问题： 模型检索到的是"曾经正确"的规则。 向量库里躺着三个月前那份政策，用户问的是"我现在退要扣多少"，它很自信地按旧规则算了一个数。这不是召回不准，是知识过期。

后来改成三件事：

• 规则结构化 ，不用自然语言存。航司代码、舱位、时间窗口、手续费率全部落字段，能算的一律走规则引擎，不让模型做算术

• 每条规则带版本和生效时间 ，只召回当前生效的那一条，过期的物理上就不该被检索到

• 政策类回答必须带生效日期 ，要能说清"这是哪天的规则"

评估集也拆开了：政策题和计算题分开分组，计算题不许模型心算，必须调规则引擎，错了直接判不及格。

面试聊这块的时候，别人说的是"我把政策文档做进了 RAG"，他说的是"我没让模型算过一分钱，能算的全走规则引擎，模型只负责找规则和说人话"。这两种回答，面试官一听就分出高下。

第三步：工具治理，接第一个很容易，难的是第五十个（4 周）

这是 OTA 和前面那些场景最大的区别。

内容社区的工具是自己家的，交易场景的工具也是自己家的， OTA 有一半工具是别人的 ——航司的、酒店的、供应商的、支付的和风控的。数量多、归属杂、还会变。

他踩的坑就是开头那个：全塞进 prompt。后来改成三层：

• 按域分层 ：机票、酒店、订单、支付、政策，先按域切开，一次对话只装载一两个域

• 意图路由 ：先用一次轻量判断决定去哪个域，再把这个域的 5-8 个工具装载进上下文。一次给模型的工具永远不超过 8 个

• 消歧 ：查航班时刻和查订单里的航班是两个工具，光靠描述模型分不清，必须写清楚"什么时候不该用"

再加一条工程上的：工具要能灰度上下线，改一个描述不能重启服务，不然每调一次就得全量回归。

他后来加工具的速度反而变快了——新增一个工具，不再需要动所有场景。

第四步：外部世界不会等你（5 周）

这是他进步最大的一块，也是普通教程完全不会讲的一块。

前面所有场景都隐含一个假设：你调的接口会返回，返回的是对的，下次调还是这个结果。OTA 里这个假设不成立——航司接口三秒不回是常态，酒店房态可能刚查完就没了，两个供应商报的价格不一样。

他一开始的处理是重试。重试解决不了不一致。后来定下来几条：

• 超时预算分级 ：关键路径给短预算，超了就降级；非关键的可以异步补

• 部分结果也要能答 ：三个源查回来两个，能答的先答，但要说清哪部分没查到，不许静默吞掉

• 时效标注 ：价格和库存必须带"我几点查到的"，答的时候原样告诉用户"可能已变动"

• 二次核验 ：真正下单扣款之前，价格必须重新查一次，这一步一个字都不能省

• 多源仲裁 ：两个源不一致时信谁要有明确规则（按供应商优先级、按更新时间），不能让模型自己挑

我跟他说过：面试的时候，这个项目就是你的全部弹药。

然后是面试：三轮技术面，一道推导都没考

他进去之前紧张得要死，拿着注意力机制推导、多智能体框架对比那类东西狂背。我让他停了。这个岗不考这个。

结果果然，三轮全在聊项目。挑两道他回来复述的：

「几百个工具，你怎么保证模型选对？」

普通答法：把工具描述写好。

他的答法：写好描述只是及格线。真正的解法是不让它选那么多次——按域分层，先用一次轻量判断做意图路由，再把那一个域的 5-8 个工具装载进去；成对相似的工具要做消歧，写清楚"什么时候不该用"；工具还得能灰度上下线，不然改一个描述就得全量回归。

「外部接口超时，或者查到的价格跟刚才不一样，怎么办？」

普通答法：加个重试。

他的答法：重试解决不了不一致。超时按预算分级，关键路径给短预算，超了就降级；价格和库存必须带时效，答的时候告诉用户这是几点查到的；真正下单前必须重新核验一次；多个源报得不一样时要有仲裁规则，不能让模型自己挑。

有一轮考系统设计，他占了个自己都没想到的便宜：七年供应商对接攒下的超时处理、缓存一致性、限流熔断、对账那套直接能用。 OTA 天天在跟不确定的外部世界打交道，而 Agent 面对外部供给时最需要的，恰好就是这套东西。

有两轮聊到后面，面试官开始跟他讨论自己业务里的问题——不像面试，像同事交流。

所以"水"到底是什么意思

考察点特别集中：全在项目上，全在取舍上。不问推导，不问框架源码，问的是"你做过没有、撞了什么、为什么这么选"。

做过的人觉得是聊天，没做过的人就是天书。

他这轮顺，说到底是方向对了——不是突然变成 AI 专家，而是他七年里最烦的那些事（超时、对不齐的账、随时会变的库存），恰好是这个岗位每天在处理的事。