阿里员工：羡慕隔壁组做 Qoder 的，感觉每天一个新花样，年终奖肯定少不了，算是踩中了 AI 时代的红利啊（附Agent面试题）
说实话，我自己也是Qoder系列产品的重度使用者，感觉确实发展快。
一开始，我看有些小伙伴反馈嫌贵，单由于接的是某海外顶级模型，价格比国内模型肯定贵一些。
但Claude Code和Codex也不是每个人都能用得上，所以Qoder反而在国内成为了不错的替代品。
他们最近新开源的 Better Harness 我看了一下，确实都是Agent时代值得去参考和借鉴的东西。
https://github.com/QoderAI/better-harness
我也第一时间接入到了我自己的Coding产品PaiCLI中。
同样开源：https://github.com/itwanger/PaiCLI-Python
就目前来说，最成功的 AI 产品当属 Claude Code和Codex，其次就是Qoder、WorkBuddy这些国内的 Agent，那“羡慕隔壁组做 Qoder 的”绝对是最真实的心声。
对于传统业务，最好的结果无非就是优化存量，但 AI 工具团队却在创造增量，说不羡慕，那绝对是嫉妒。😄
AI Coding 方向的迭代速度极快，团队每天都有新的、可见的产出。在大厂，可见的产出等于可见的绩效。可见的绩效等于年底的丰厚年终奖。
原因很简单——程序员是大模型落地最直接的用户群体，AI Coding 工具的使用频次和付费意愿远高于其他场景。再加上，Agent 让那些原本不具备开发能力的群体也能产出自己的产品。
这意味着 Agent 方向的岗位未来两三年只会越来越多。
限流、熔断、异步队列、幂等设计、调用追踪、灰度发布——这些在三高时代积累的工程能力，在 Agent 产品化的过程中一个都不能少。
以前管的是 HTTP 请求，现在你管的是 LLM 调用。上下文窗口是新的内存管理，token 预算是新的 QPS 限流，工具调用是新的 RPC 网关。
做 Agent 不需要去训模型、搞推理加速、写 CUDA。它需要的是你能把大模型的能力包装成一个可靠的服务——能扛住流量、能处理异常、能追踪问题、能持续迭代。
如果你是一位愿意在自己的节奏下学一些新东西的人，那接下来这份 Agent 面试题，可以好好读一读。
（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗粗发～）
场景题
在淘天高并发场景下，将 Agent Demo 改造为能支撑“双十一”级别流量的生产系统，最大的架构挑战是什么？
老王翻了翻简历上的项目经历，开口就是一个很难的场景题：“假设你来我们淘天，要把一个实验性质的 Agent Demo 改造成能扛双十一的生产系统，你觉得最大的架构挑战是什么？”
“最大的挑战是 LLM API 会成为单点瓶颈。”
“传统微服务扛流量的思路是水平扩容——流量大了加实例，实例不够加节点。但 Agent 系统的核心依赖是 LLM API 调用，这东西有三个特性让它没法用传统思路来扩。”
“第一，延迟量级不同。HTTP 接口的响应时间是毫秒级，LLM 接口是秒级。一个 Agent 处理一次用户请求可能需要 3 到 5 次 LLM 调用，每次两三秒，加起来就是十几秒，长程任务甚至需要几个小时。传统的同步请求模型在这种延迟下会把线程池打满。”
“第二，QPS 有上限。不管你扩多少个 Agent 实例，它们都在调同一个 LLM 端点。模型提供商给你的 RPM（Requests Per Minute，每分钟请求数）配额是固定的，假如是 1 万次/分钟，10 个 实例 和 100 个 实例 分到的总额度没变。”
“第三，成本随调用量线性增长。每次 LLM 调用按 token 计费，双十一峰值可能是平时的 50 到 100 倍，成本也跟着翻这么多。”
“针对这三个问题，我的应对方案分四层。”
“第一层，语义缓存（Semantic Cache）。把用户查询做 Embedding，在缓存里找语义相似的历史查询。双十一场景下大量问题是重复的——‘我的快递到哪了’‘怎么申请退款’‘能用几个红包’。这类高频问题命中缓存后直接返回，不走 LLM。”
“第二层，模型分级路由。不是所有请求都需要最强的模型。简单查询（订单状态、物流追踪）走小参数模型甚至走规则引擎，只有复杂的多轮对话才走大模型。路由的依据是意图分类器的输出，分类器本身用轻量模型或者规则匹配就行。”
“第三层，全流程异步化。用户请求进来先入 RocketMQ，Agent Worker 从队列消费。削峰填谷的同时也解决了线程池打满的问题。实时场景设超时兜底，超时就降级到模板回复。”
“第四层，工具调用熔断。Agent 执行过程中会调外部 API——库存服务、物流服务、支付服务。双十一这些下游服务自己也在扛流量，随时可能超时。每个工具调用加 Sentinel 熔断器，错误率超过阈值直接短路。同时所有工具调用都做幂等设计，防止重试导致重复下单或重复退款。”
为什么不能直接水平扩容 Agent 实例？
“因为瓶颈在 LLM API，不在计算资源。”
“假设 LLM 端点的 RPM 上限是 1 万次/分钟，你扩 10 个 实例 还是 100 个 实例，能发出去的请求总量没变。100 个 实例 只是让更多线程同时排队，排队速度不会变快。”
“真正能提升吞吐的是减少 LLM 调用次数——语义缓存、模型分级、规则引擎前置——把有限的额度留给真正需要大模型推理的请求。”
content
01、在构建 Agent 框架时，选择 LangChain/LlamaIndex 还是自研？
老王端起茶杯抿了一口：“框架选型这块，你怎么看 LangChain 这类开源框架和自研？”
“这个问题我有实际经验。PaiCLI 的核心 Agent 循环是自研的，基于 Spring AI 做模型层抽象。另一个项目 PaiAgent 用了 LangGraph4j 做复杂的 DAG 工作流编排。”
“先说 LangChain 的优势。生态是真的强，500 多个集成，向量数据库、模型提供商、工具连接器几乎全覆盖。做 POC 验证想法，差不多两三天就能出一个能跑通的 Demo。社区活跃，遇到问题基本都能搜到解法。”
“但它的问题也是真实存在的。”
“第一，调试成本高。一个简单的工具调用，经过好几层框架内部的包装，报错时堆栈太多。你想知道‘为什么这次工具调用返回了空’，得先理解框架的内部状态。”
“第二，版本是历史包袱。LangChain 早期从 0.1 到 0.2 到 0.3 几乎是三个不同的框架，API 断裂式变更。虽然到了 1.x 稳定了不少，但这段历史说明一件事——你的生产代码依赖别人的迭代节奏，这本身就是风险。”
“第三，抽象。框架的设计是通用的，但你的业务是完全不同的。为了适配，你得写大量代码把自己的逻辑塞进框架的接口里。”
“自研的优势是完全掌控每一步。调试直接看自己的代码，性能瓶颈知道在哪，迭代节奏自己定。况且现在 Agent 的 Coding 能力已经很强了，完全不用担心自研。”
“我的判断——做技术验证和快速原型，用框架。做生产系统，核心自己写，框架当工具库用。”
02、如何控制 Agent 的自主性边界？如何设计安全护栏？
“自主性边界的核心原则——确定性的规则走规则引擎，模糊的地方交给 LLM 判断，高风险动作交给人工审批。”
“拿退换货场景举例。‘7 天无理由退货’是确定性规则——在时间窗口内、商品未拆封，直接走退货流程，不需要 Agent 做任何推理。这类场景用规则引擎处理，速度快、结果一致、成本为零。”
“‘商品有轻微使用痕迹，用户申请退货’是模糊地带——需要 Agent 根据图片判断损坏程度、参考历史类似案例、结合用户信誉评分，给出一个建议。”
“‘退款金额超过 1000 元’是高风险动作——不管 Agent 怎么判断，最终执行前都要人工确认。”
“安全护栏分三层。”
“第一层，输入哨兵。请求进来先过内容过滤器，拦截违规内容。然后做意图分类，如果用户的意图超出 Agent 的职能范围——比如问内部系统架构、要求查其他用户的隐私信息——直接拒绝，不进入 Agent 流程。”
“第二层，执行围栏。Agent 运行过程中只能调用预注册的工具，调用参数有校验规则。路径操作限定在白名单目录内，防止路径穿越攻击。危险命令走黑名单拦截。每一步工具调用都有结构化的审计日志，记录输入、输出、时间戳、调用者身份。”
“第三层，输出审查。Agent 生成的回复在返回用户之前，过一遍合规检查——有没有泄露内部政策细节、有没有承诺超出权限的补偿方案、有没有包含敏感信息。”
为什么不能完全信任 Agent 的推理？
“因为 LLM 是概率模型，同样的输入不保证同样的输出。”
“在退换货场景下，同一个退货申请，Agent 第一次可能回复‘符合政策，已提交退款’，第二次可能回复‘建议您联系人工客服进一步确认’。如果涉及到真金白银的退款操作，这种不确定性是不可接受的。”
“概率模型处理需要判断力的部分，规则引擎处理需要一致性的部分，人工兜底处理需要承担责任的部分。三者各管各的，边界清晰。”
03、Agent 的幻觉和不合规内容，在工程层面有哪些控制和拦截机制？
老王推了推眼镜：“幻觉问题大家都知道，我想听的是工程层面怎么落地。”
“分两个阶段，生成前和生成后。”
“生成前的核心手段是 RAG。把相关的事实性内容从知识库检索出来，注入到上下文里。模型基于提供的证据回答，减少幻觉的发生。”
“但 RAG 不能完全消除幻觉。模型有可能无视上下文里的事实，自己编一个‘看起来很合理’的答案。所以系统提示词里要加硬性约束——‘只根据提供的上下文回答，如果上下文中没有相关信息，明确告知用户你不确定’。”
“对于时效性强的查询——商品价格、库存状态、物流进度——在调 LLM 之前先走一次 API 预检，把实时数据拿到手再塞进上下文。不给模型‘猜’的机会。”
“生成后的拦截分四道关卡。”
“第一道，结构化校验。回复里如果包含 URL，检查 URL 格式是否合法。如果包含价格或日期，检查是否在合理范围内。如果包含 JSON 或代码块，检查语法是否正确。这些是纯规则的校验，不需要模型参与，速度快、零成本。”
“第二道，引用核实。模型如果声称‘根据退换货政策第三条’，就去验证这一条是否真实存在、内容是否匹配。”
“第三道，模型裁判（LLM-as-Judge）。用另一个模型审查回复的事实准确性。成本不高，因为审查用的 prompt 比生成用的 prompt 短得多。”
“第四道，置信度兜底。如果模型输出的 logprob（每个 token 的对数概率，反映模型对自己答案的把握程度）低于阈值，说明模型自己也拿不准，这条回复直接转人工。”
04、为 Agent 增加“通过商品图片找同款”的多模态能力，后端架构需要哪些改造？
老王看了一眼简历上的技术栈：“业务方提了个需求，用户拍一张商品图片，Agent 帮忙找同款。你的后端架构要怎么改？”
“改动集中在四个模块。”
“第一，新增图片处理流程。前端上传图片后，后端先做预处理——格式校验，只接受 JPEG、PNG、WebP。大小限制在 5MB 以内。分辨率做好校验，太大的缩放到标准尺寸，避免耗时过长。”
“第二，引入视觉编码模型。用 CLIP（Contrastive Language-Image Pre-training，对比式语言-图像预训练）把图片编码成稠密向量。CLIP 在训练阶段把图片和文本映射到了同一个向量空间，所以图片向量和文字描述的向量可以直接计算相似度。商品库里所有图片要提前跑一遍离线编码，把向量存进向量数据库。”
“第三，新建图片向量索引。在 Milvus 里单独建一张表存商品图片向量，索引类型选 HNSW（一种针对向量检索优化的索引结构），查询延迟在毫秒级。用户上传图片 → CLIP 编码 → 向量检索 → 返回最相似的几个商品。”
“第四，结果融合与重排序。向量检索拿到的是视觉相似的商品，但‘看起来像’不等于‘是同款’。需要一个重排序，综合视觉相似度、品类匹配度、价格区间、用户历史偏好，重新排序后返回。”
为什么图片向量和文本向量不能混用同一个索引？
“因为不同 Embedding 模型产出的向量空间语义不兼容。”
“纯文本检索常用的 Embedding 模型，比如千问 Embedding，和 CLIP 的文本编码器产出的向量，虽然维度可能相同，但向量空间的语义结构完全不同。把它们扔进同一个索引算余弦相似度，得到的分数没有实际意义。”
“CLIP 本身确实能做跨模态检索——用文字查图片，或者用图片查文字——因为它自己的文本编码器和图片编码器在同一个空间里。但这种映射只限于 CLIP 自己的编码器对，不能和其他模型的向量混在一起。”
“生产环境的做法是维护多套索引——纯文本检索走 BGE 索引精度更高，图片检索和跨模态检索走 CLIP 索引，最终在应用层做结果融合和重排序。”
05、如何保持技术敏锐度并学习一项新技术？
老王换了个方向：“聊聊你个人。怎么保持技术敏锐度的？”
“三个习惯——筛选信息源、动手验证、输出倒逼输入。”
“信息源我固定关注三个渠道。GitHub Trending 每天刷半个小时，一周涨 1000 星以上的大概率有真东西。X 上关注了一批一线开发者的账号，看他们每天在研究什么新鲜的东西。”
“看到一个新框架或者新工具，我会做一个最小可用的东西出来。比如第一次接触 MCP 协议的时候，花一个半小时写了一个 MCP Server 的简单实现，跑通之后对协议的理解更深了。”
“最后是输出。写一篇文章或者在团队内部做一次分享。写的过程中会发现自己哪里理解得模棱两可，倒逼你把细节搞清楚。”
06、和团队成员在技术方案上产生严重分歧时怎么处理？
“真碰到过。之前在选搜索方案的时候，我主张用 Elasticsearch 做混合搜索，同学认为纯向量数据库就够了。”
我的解决方案是。
“第一步，把争论变成可量化的对比。我们各自跑了一组查询测试，ES 混合搜索的召回率明显比纯向量高，但查询延迟也更长。数据摆出来之后，争论的焦点就从‘谁的方案好’变成了‘召回率和延迟哪个更重要’。”
“第二步，找第三方确认优先级。另外一个同学说在他们的场景下搜不到比搜得慢严重得多，召回率优先。方案就定了。”
“核心是把观点变成数据，把判断权交给业务约束，限时做决定。”
07、AI Native 应用与传统软件工程在开发模式上有什么差异？
老王转了转无名指上的戒指：“你怎么看 AI Native 和传统开发的差异？”
“三个差异。”
“第一，确定性变成了概率性。传统服务，同样的输入永远返回同样的输出，测试写断言就行。AI 应用，同样的 prompt 每次可能返回不同的结果。测试方法得从断言转向评估——准确率、相关性评分、人工抽检一致率。”
“第二，迭代方式变了。传统开发是写代码、发版本、上线。AI 应用的迭代很大一部分是调 prompt、换检索策略、改评估标准。代码可能一行没改，但系统行为完全不同。版本管理的对象从代码扩展到了配置——prompt 版本、模型版本、检索参数版本都要管。”
“第三，团队协作模式不同。传统开发有明确的产品文档，开发按文档实现。AI 应用很多时候产品经理也说不清‘好的输出长什么样’，需要开发、产品、运营一起定义评估标准，反复迭代。”
优秀的 AI 应用研发工程师应该具备哪些素质？
“工程能力，这个没变。但还需要对模型行为有判断的直觉——你得知道‘这个 prompt 大概率能让模型给出什么样的回复’，知道‘这类任务用 ReAct 模式比纯生成靠谱’。这种直觉是靠大量实践积累的。”
“还有一个容易被忽视的——评估思维。做任何 AI 功能，第一步应该是定义‘什么算好’，而不是直接开始写代码。没有评估标准，改了也不知道是变好了还是变差了。”
08、最近读过的一本技术书籍是什么？
老王看了一眼手表：“最后一个问题。最近读过的一本技术书，给你带来的最大启发是什么？”
“最近重读了 Chip Huyen 的《Designing Machine Learning Systems》。”
“这本书有一个观点我特别认同——大多数 ML 项目没达到预期，原因不是模型不够好，是评估做得不够好。你都不知道什么算‘好’，怎么可能做出好的系统？”
“做 Agent 也是一样的。很多团队大部分时间在调 prompt 和换模型，评估反而花的时间最少。改了之后到底变好了还是变差了，没人说得清。”
“这本书让我养成了一个习惯——做任何 AI 相关的功能，第一步是定义评估指标和测试集，然后再动手开发。”
PaiCLI 如何写到简历上？
项目名称：PaiCLI — 终端 AI Agent 命令行工具
项目简介：对标 Claude Code 的 Java 版终端 Agent，支持 ReAct、Plan-and-Execute、Multi-Agent Team 三种执行模式，具备多轮对话、代码搜索、工具调用、安全管控等能力。
技术栈：Java 21 + Spring AI + Elasticsearch + MCP 协议 + RocketMQ + Sentinel
核心职责：
- 设计 Agent 生产架构，引入语义缓存减少 60% 以上重复 LLM 调用，通过模型分级路由和消息队列异步处理实现流量削峰，支撑高并发场景下的服务稳定
- 构建三层安全护栏，实现路径白名单和危险命令黑名单，结合人机审批机制，工具调用合规率达到 99.9%
- 集成 RAG 事实注入、实时数据预检、结构化输出校验和模型裁判减少模型幻觉，关键场景的事实准确率提升了约 25%
- 实现多模态检索能力，基于 CLIP 模型完成商品图片向量化编码，独立维护图片向量索引，支持以图搜图和图文混合检索，检索响应时间控制在 50ms 以内
- 搭建 Agent 工作流评估体系，接入 Better Harness 评估框架，覆盖任务理解、受控执行、变更验证、可靠交付、学习积累，保障迭代过程中 Agent 整体的质量
ending
以前做后端，拼的是高并发、分布式、中间件。现在做 Agent，拼的是上下文管理、安全护栏、幻觉控制、效果评估。
技术栈在变，但工程能力的底层逻辑没变——谁能把系统做稳定、做可靠、做到生产级，谁就是稀缺的。
加油吧，兄弟姐妹们。
下期见。