Agent 延迟监控、高并发改造、自主性边界、幻觉治理与协作分歧等开放场景题的作答，作答结合 CodeAgent CLI 的实际实现。

场景题｜如果 Agent 突然出现延迟升高，应当监控 Token、显存、内存和工具调用中的哪些指标？

如果 Agent 突然出现延迟升高，应当监控 Token、显存、内存和工具调用中的哪些指标？

“分四个维度看。”

“Token 维度先查输入 token 数。如果最近几轮的输入 token 突然变大，说明上下文在膨胀——可能是压缩没触发，也可能是某次工具调用返回了大量数据没做截断。再查 Prompt Cache 的命中率，命中率下降意味着每次请求都要重新计算完整的上下文，延迟和成本同时上升。”

“显存和内存维度看 KV Cache 的占用量和 batch 队列深度。KV Cache 占用接近显存上限的时候，新请求只能排队等老请求释放，延迟自然上升。内存方面看进程的常驻内存占用，如果持续增长不回落，可能有内存泄漏或者某个 Agent 的上下文一直在膨胀没被压缩。”

“工具调用维度查三个指标：单次工具调用的耗时、是否有超时重试、调用频率有没有异常增长。CodeAgent CLI 的审计日志里记录了每次工具调用的名称、参数、耗时和结果状态，查日志一眼就能定位到是哪个工具拖慢了整体。”

“系统维度看 GPU 利用率和网络延迟。GPU 利用率打满说明算力不够用了，利用率很低但延迟高说明瓶颈不在计算而在数据传输或排队。如果 Agent 要调用外部 API，网络延迟的波动也需要关注。”

场景题｜在淘天高并发场景下，将 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 调用次数——语义缓存、模型分级、规则引擎前置——把有限的额度留给真正需要大模型推理的请求。”

场景题｜如何控制 Agent 的自主性边界？如何设计安全护栏？

如何控制 Agent 的自主性边界？如何设计安全护栏？

“自主性边界的核心原则——确定性的规则走规则引擎，模糊的地方交给 LLM 判断，高风险动作交给人工审批。”

“拿退换货场景举例。‘7 天无理由退货’是确定性规则——在时间窗口内、商品未拆封，直接走退货流程，不需要 Agent 做任何推理。这类场景用规则引擎处理，速度快、结果一致、成本为零。”

“‘商品有轻微使用痕迹，用户申请退货’是模糊地带——需要 Agent 根据图片判断损坏程度、参考历史类似案例、结合用户信誉评分，给出一个建议。”

“‘退款金额超过 1000 元’是高风险动作——不管 Agent 怎么判断，最终执行前都要人工确认。”

“安全护栏分三层。”

“第一层，输入哨兵。请求进来先过内容过滤器，拦截违规内容。然后做意图分类，如果用户的意图超出 Agent 的职能范围——比如问内部系统架构、要求查其他用户的隐私信息——直接拒绝，不进入 Agent 流程。”

“第二层，执行围栏。Agent 运行过程中只能调用预注册的工具，调用参数有校验规则。路径操作限定在白名单目录内，防止路径穿越攻击。危险命令走黑名单拦截。每一步工具调用都有结构化的审计日志，记录输入、输出、时间戳、调用者身份。”

“第三层，输出审查。Agent 生成的回复在返回用户之前，过一遍合规检查——有没有泄露内部政策细节、有没有承诺超出权限的补偿方案、有没有包含敏感信息。”

为什么不能完全信任 Agent 的推理？

“因为 LLM 是概率模型，同样的输入不保证同样的输出。”

“在退换货场景下，同一个退货申请，Agent 第一次可能回复‘符合政策，已提交退款’，第二次可能回复‘建议您联系人工客服进一步确认’。如果涉及到真金白银的退款操作，这种不确定性是不可接受的。”

“概率模型处理需要判断力的部分，规则引擎处理需要一致性的部分，人工兜底处理需要承担责任的部分。三者各管各的，边界清晰。”

场景题｜Agent 的幻觉和不合规内容，在工程层面有哪些控制和拦截机制？

Agent 的幻觉和不合规内容，在工程层面有哪些控制和拦截机制？

“分两个阶段，生成前和生成后。”

“生成前的核心手段是 RAG。把相关的事实性内容从知识库检索出来，注入到上下文里。模型基于提供的证据回答，减少幻觉的发生。”

“但 RAG 不能完全消除幻觉。模型有可能无视上下文里的事实，自己编一个‘看起来很合理’的答案。所以系统提示词里要加硬性约束——‘只根据提供的上下文回答，如果上下文中没有相关信息，明确告知用户你不确定’。”

“对于时效性强的查询——商品价格、库存状态、物流进度——在调 LLM 之前先走一次 API 预检，把实时数据拿到手再塞进上下文。不给模型‘猜’的机会。”

“生成后的拦截分四道关卡。”

“第一道，结构化校验。回复里如果包含 URL，检查 URL 格式是否合法。如果包含价格或日期，检查是否在合理范围内。如果包含 JSON 或代码块，检查语法是否正确。这些是纯规则的校验，不需要模型参与，速度快、零成本。”

“第二道，引用核实。模型如果声称‘根据退换货政策第三条’，就去验证这一条是否真实存在、内容是否匹配。”

“第三道，模型裁判（LLM-as-Judge）。用另一个模型审查回复的事实准确性。成本不高，因为审查用的 prompt 比生成用的 prompt 短得多。”

“第四道，置信度兜底。如果模型输出的 logprob（每个 token 的对数概率，反映模型对自己答案的把握程度）低于阈值，说明模型自己也拿不准，这条回复直接转人工。”

场景题｜和团队成员在技术方案上产生严重分歧时怎么处理？

和团队成员在技术方案上产生严重分歧时怎么处理？

“之前在选搜索方案的时候，我主张用 Elasticsearch 做混合搜索，同学认为纯向量数据库就够了。”

我的解决方案是。

“第一步，把争论变成可量化的对比。我们各自跑了一组查询测试，ES 混合搜索的召回率明显比纯向量高，但查询延迟也更长。数据摆出来之后，争论的焦点就从‘谁的方案好’变成了‘召回率和延迟哪个更重要’。”

“第二步，找第三方确认优先级。另外一个同学说在他们的场景下搜不到比搜得慢严重得多，召回率优先。方案就定了。”

“核心是把观点变成数据，把判断权交给业务约束，限时做决定。”

八股延伸｜使用 AI 时，如何保证输出内容的质量

使用 AI 时，如何保证输出内容的质量

“分三层答，先说我实现了的。”

• 写后自检：写入或修改 Python 文件后立即做语法编译检查，报错附在工具结果里回给模型，让它当轮就改
• 审查重试：多 Agent 模式里有专职的审查者角色，产出不合格打回重做，每步最多重试 2 次
• 安全兜底：危险命令黑名单、路径守卫、高危操作人工确认、全程审计日志，外加任务前后各打一次快照，随时可回滚

这些都是工程手段，提示词层面呢？

“三条实践。把验收标准直接写进提示词，让模型知道什么叫合格；复杂任务要求模型先复述一遍理解再动手，提前暴露偏差；重要产出让模型对照标准自查一轮再交付。”

“也坦白说，通用的钩子机制和结构化输出校验我还没做，主循环也没有自动重试。这道题面试时最忌讳把没做的说成做了——质量保证的第一条，是先保证自己说的话是真的。”