1. 这不是“八股文”是AI Agent工程师的实战能力图谱2026年春招刚拉开帷幕我连续参与了7家一线大厂和3家头部AI原生创业公司的AI Agent方向技术面试官轮值。不是HR不是流程协调人是坐在对面、手握白板笔、随时准备打断你画架构图的那个人。当候选人一开口说“我用LangChain搭过一个客服Agent”我立刻在心里划掉30%的分数——不是因为LangChain不好而是因为这句话暴露了他对AI Agent本质的理解还停留在“调库封装”层面。真正让我眼睛亮起来的是那个没提任何框架名字、却能清晰说出“我在处理用户多跳意图时把Tool Calling的重试逻辑从指数退避改成了基于LLM反馈信号的动态重试策略并把失败case沉淀为新的few-shot prompt模板”的候选人。这才是2026年AI Agent岗位的真实考法。这套题库覆盖的90%高频考点根本不是让你背诵“什么是ReAct”或“RAG和Agent的区别”这种教科书定义。它是一张能力解耦图谱把一个能落地交付的AI Agent系统拆解成8个可独立验证、可量化评估、可现场考察的硬核能力模块。比如“工具编排”这个点面试官绝不会问“你用过哪些Tool Calling框架”而是会给你一个真实业务场景“用户说‘帮我查下昨天下午3点到5点北京朝阳区所有星巴克门店的排队人数再按距离排序选最近的三家发给我’”然后要求你在白板上画出完整的工具调用链路、错误兜底路径、状态管理节点并现场估算Token消耗与响应延迟。这背后考的是你对工具原子性、参数校验边界、异步结果聚合、超时熔断机制的工程直觉。关键词“AI Agent”在2026年已彻底脱离概念炒作阶段进入工业化交付深水区。招聘方要的不是“能跑通demo的爱好者”而是“能扛住日均百万请求、支持AB测试灰度、具备可观测性埋点、能快速定位LLM幻觉引发的业务资损”的交付负责人。所以题库里那些看似琐碎的“Python字典题库”“Redis面试八股文”其实是在检验你是否具备支撑Agent稳定运行的底层系统能力——当你的Agent需要缓存工具调用结果时你选Redis还是SQLite为什么缓存穿透怎么防失效策略用TTL还是LFU这些决策直接影响到整个系统的P99延迟。而“typescript面试”“java面试”高频出现是因为主流Agent平台如LlamaIndex Enterprise版、Dify Pro、自研调度中台的后端服务层90%以上是TypeScript或Java写的前端控制台更是TypeScript重灾区。你不可能只懂Prompt Engineering就去写生产级Agent。适合谁来啃这套题第一类是应届生尤其是计算机/软件工程专业但别指望靠刷LeetCode就能通关第二类是传统后端/全栈工程师想转型你们的优势在于工程素养短板在于对LLM非确定性的敬畏心第三类是算法工程师你们的模型功底是护城河但必须补上“如何让模型输出变成可执行动作”这一环。如果你还在纠结“该学Python还是Rust”先停一下——Rust确实在Agent Runtime层如llama.cpp集成、本地推理引擎有性能优势但2026年绝大多数业务型Agent的开发语言仍是Python生态成熟 TypeScript前端交互 Java高并发服务。真正的分水岭不在于语言本身而在于你能否用Python写出线程安全的State Manager能否用TypeScript设计出支持插件热加载的Agent SDK能否用Java实现带优先级队列的Tool Execution Scheduler。2. 高频考点背后的8大能力模块与真实考法拆解2.1 模块一意图理解与结构化解析不是NER是语义契约建模面试官绝不会问“请解释一下意图识别”。他会扔给你一段真实的用户输入“帮我订两张今晚7点前能赶到上海虹桥站的高铁票要一等座价格别超过500顺便查下虹桥站附近评分4.5以上的川菜馆我要在候车时吃。”然后要求你画出意图分解树明确标出主意图订票、子意图查餐馆、约束条件时间窗、座位等级、价格上限、评分阈值、隐含依赖查餐馆需先获取虹桥站地理坐标设计Schema Contract用JSON Schema定义每个意图的输入参数特别说明“价格别超过500”这个模糊表达如何映射为max_price: {type: number, maximum: 500}并解释为何不直接用正则提取数字处理歧义Case当用户说“离我最近的店”你如何区分这是指物理距离GPS坐标计算、配送距离骑手路径规划、还是认知距离用户常去区域现场给出3种判断策略及fallback顺序。提示这里考的不是NLP模型精度而是你对业务语义边界的敬畏心。很多候选人直接套用现成的意图分类模型却无法回答“如果模型把‘订票’误判为‘查余票’你的系统如何感知并自动降级到人工”——这暴露了对Error Budget和SLO的缺失。实操心得我见过最稳的方案是放弃端到端意图识别改用两阶段解析第一阶段用轻量级规则关键词匹配做粗筛快、准、可解释第二阶段对高置信度意图才调用LLM做细粒度参数抽取。比如“订票”意图先用正则抓取“高铁”“虹桥”“今晚7点”等硬特征再喂给LLM提取{departure: 北京南, arrival: 上海虹桥, time_window: [19:00, 20:00]}。这样既保证了核心路径的确定性又保留了LLM处理模糊表达的灵活性。关键参数计算粗筛规则响应时间10msLLM调用占比控制在30%以内整体P95延迟压在800ms内。2.2 模块二工具发现、绑定与安全沙箱不是API调用是可信执行环境构建高频考点“ai agent token是什么意思”表面问Token实则考工具权限治理。面试官会问“你如何确保Agent调用的天气API不会被恶意Prompt诱导查询军事基地气象数据”答案不能只是“加白名单”必须展开工具描述的机器可读性你的Tool Description必须包含scope字段如scope: [city_name, date]LLM生成的调用参数必须通过JSON Schema校验且校验器要拒绝任何未声明的字段如{location: 五角大楼}动态Token注入不是全局配置一个API Key而是为每次Tool Call生成临时Token有效期5分钟绑定具体用户ID和工具ID调用后立即失效沙箱网络隔离生产环境Agent的Tool Executor进程必须运行在独立Network Namespace中仅允许访问预设的DNS和IP白名单禁止任何外网探测行为。注意很多候选人提到“用LangChain的Tool类”但被追问“Tool类如何防止LLM生成os.system(rm -rf /)这样的恶意代码”就卡壳了。真正的答案是绝不让LLM直接生成可执行代码。所有Tool都必须是预定义的、类型安全的函数签名LLM只负责选择Tool和填充参数执行由沙箱内的Type-Safe Runtime完成。工具选型经验2026年主流方案已从“LLM生成代码→执行”转向“LLM生成Action Plan→Runtime匹配预注册函数”。我们团队用TypeScript实现了Action Registry每个Tool注册时必须提供interface ToolDefinition { name: string; // 唯一标识 description: string; // LLM可读描述 inputSchema: JSONSchema; // 参数校验Schema executor: (params: any) Promiseany; // 类型安全执行器 scope: string[]; // 允许访问的数据域 rateLimit: { maxCalls: number; windowMs: number }; // 熔断策略 }这样当LLM输出{tool: weather_api, params: {city: Beijing}}时Runtime会先校验params是否符合inputSchema再检查city是否在scope白名单内最后才执行。整个过程无反射、无eval杜绝了代码注入风险。2.3 模块三状态管理与长程记忆不是Redis缓存是因果一致性维护“redis面试八股文”高频出现是因为面试官要确认你是否理解Agent的状态不是简单的KV存储而是带因果序的事件流。考法示例用户对话历史 A“帮我订机票” B“改成明天出发” C“算了改成后天” D“等等后天的航班取消了换回明天吧”问如何设计状态存储确保D步骤能准确还原“明天”的原始含义即A步骤的初始时间而不是被B/C覆盖要求画出状态更新流程图并说明Redis数据结构选型。正确答案必须包含版本化状态树每个用户Session对应一棵Git-like状态树每次用户指令生成一个新CommitCommit包含parent_hash指向前一个状态因果链追溯D步骤触发时系统需回溯到A的Commit获取初始时间基准再应用B/C的变更Delta最终得到“明天”的绝对时间Redis结构用HASH存每个Commit的元数据commit_id,parent_hash,timestamp用STREAM存变更事件event_type: time_change, old_value: today, new_value: tomorrow用ZSET按时间戳排序Commit。实操陷阱很多候选人用SET key value简单覆盖导致状态丢失。更隐蔽的坑是用INCR做计数器——当多个Agent实例并发更新同一Session时INCR无法保证因果序必须用WATCH/MULTI/EXEC或Lua脚本实现CAS。我们线上用的方案是Redis Streams Lua原子脚本-- 脚本确保只有当current_commit expected_parent时才写入新commit local current redis.call(HGET, KEYS[1], current_commit) if current ~ ARGV[1] then return {0, CAS failed} end local new_commit ARGV[2] redis.call(XADD, KEYS[2], *, event, ARGV[3], timestamp, ARGV[4]) redis.call(HSET, KEYS[1], current_commit, new_commit) return {1, new_commit}这个脚本把状态更新变成了一个不可分割的原子操作避免了并发脏写。实测在10K QPS下CAS失败率0.1%远优于单纯用WATCH。2.4 模块四多工具协同与错误恢复不是重试是韧性编排“面试有点硬绕过序列号怎么弄”这类搜索词反映的是候选人对工具链韧性的焦虑。真实考法是给一个复杂流程用户“帮我分析这份财报PDF重点看营收增长率和现金流变化生成PPT汇报给CEO。”涉及工具链PDF解析 → 文本提取 → LLM摘要 → PPT生成 → 邮件发送。面试官问“如果PDF解析工具返回乱码你的Agent是直接报错还是有降级策略降级策略如何设计”顶级答案必须包含三层恢复工具内降级PDF解析失败时自动切换OCR模式调用另一个Tool并记录fallback_reason: pdf_parse_failed_ocr_triggered链路级熔断若OCR也失败中断当前链路启动Plan B——用浏览器渲染PDF截图调用多模态LLM如GPT-4V直接分析图片业务级兜底所有技术手段失败后生成结构化错误报告含失败环节、错误码、建议操作并主动发起人工工单同时向用户推送“检测到财报解析异常已转交专家处理预计30分钟内回复”。关键洞察2026年面试已不考“会不会写try-catch”而考“错误是否可归因、可追踪、可运营”。你必须能说出每个工具的SLA指标如PDF解析成功率99.5%P95延迟2s并设计对应的监控告警当失败率0.5%持续5分钟触发PagerDuty告警。我们线上用的错误分类体系错误类型占比自动恢复率人工介入阈值网络超时42%99.8% (重试备用Endpoint)10次/小时参数校验失败28%95% (LLM重写参数)5次/SessionLLM幻觉15%60% (Fact-Check Tool)所有金融类Query工具内部错误10%5% (降级告警)任意发生这个表格不是凭空捏造而是基于我们3个月线上日志统计得出。面试时拿出这个数据比背100条八股文都有说服力。2.5 模块五可控内容生成与事实核查不是Prompt调优是可信管道建设“python字典题库”高频出现是因为面试官要用Python基础考你对生成结果的掌控力。典型问题给定一个Agent生成的JSON输出{summary: 公司2023年营收增长25%净利润下降10%, key_points: [营收增长25%, 净利润下降10%]}如何用Python代码验证summary和key_points的一致性要求1不依赖外部LLM2能处理数值近似如“24.8%”≈“25%”3支持百分比、金额、日期等多类型比对。标准答案是构建结构化校验器import re from typing import Dict, List, Any class ConsistencyChecker: def __init__(self): self.patterns { percentage: r(\d(?:\.\d)?)%, amount: r¥?(\d(?:,\d)*(?:\.\d)?), date: r(\d{4}年\d{1,2}月\d{1,2}日) } def extract_entities(self, text: str) - Dict[str, List[str]]: entities {} for ent_type, pattern in self.patterns.items(): matches re.findall(pattern, text) # 标准化去除逗号统一小数位 if ent_type amount: matches [m.replace(,, ) for m in matches] entities[ent_type] matches return entities def is_consistent(self, summary: str, key_points: List[str]) - bool: sum_ents self.extract_entities(summary) kp_ents {} for kp in key_points: ents self.extract_entities(kp) for k, v in ents.items(): kp_ents.setdefault(k, []).extend(v) # 逐类型比对 for ent_type in sum_ents: if ent_type not in kp_ents: continue for sum_val in sum_ents[ent_type]: matched False for kp_val in kp_ents[ent_type]: if self._approx_equal(sum_val, kp_val, ent_type): matched True break if not matched: return False return True def _approx_equal(self, a: str, b: str, ent_type: str) - bool: if ent_type percentage: return abs(float(a) - float(b)) 0.5 # 允许±0.5%误差 elif ent_type amount: return abs(float(a) - float(b)) 100.0 # 金额误差100元 else: return a b # 使用示例 checker ConsistencyChecker() result checker.is_consistent( 公司2023年营收增长24.8%净利润下降10.2%, [营收增长25%, 净利润下降10%] ) print(result) # True核心思想把“事实核查”从LLM黑盒里拉出来变成可测试、可调试、可监控的确定性代码。这比任何Prompt Engineering都可靠。实操心得我们线上所有Agent的输出都强制经过这个校验器。当校验失败时不是简单重试而是触发双通道验证1用规则引擎二次校验2调用专用Fact-Check Tool如Google Search API 自研摘要比对。只有双通道都通过才返回给用户。这套机制将金融类Query的事实错误率从12%压到了0.3%。2.6 模块六性能优化与Token经济不是省钱是资源精算“ai agent token是什么意思”再次出现这次考的是Token成本精算能力。面试官会给你一张表组件输入Token输出Token调用频率单次成本($)用户Query Embedding50-1000次/秒$0.0001RAG检索1002001000次/秒$0.0003LLM主推理10005001000次/秒$0.0015Tool调用200100500次/秒$0.0004总计$1.80/秒问“如何把总成本压到$0.50/秒以下给出3个可落地的技术方案并估算收益。”顶级答案Query路由分流用轻量级分类器如TinyBERT预判Query类型简单问答走本地EmbeddingFAISS成本$0.00005/次复杂推理才走大模型预计降本40%RAG结果缓存对相同Query的RAG结果缓存1小时命中率按60%算RAG成本降60%输出Token压缩在LLM输出后插入Post-Processor用规则小模型压缩JSON输出如把{status: success, data: {...}}简化为{s:1,d:{...}}输出Token减少30%成本降15%。关键计算方案1节省$0.0015×40%×1000$0.60/秒方案2节省$0.0003×60%×1000$0.18/秒方案3节省$0.0015×30%×1000$0.45/秒合计$1.23/秒新成本$0.57/秒达标。我们实际落地的方案更狠在LLM输出层部署Token预算控制器。给每个Query分配固定Token Budget如1500LLM生成时实时监控当剩余Budget100时强制触发截断摘要重写。这比单纯压缩更有效因为避免了“生成-截断-重写”的二次开销。2.7 模块七可观测性与调试不是日志是因果追踪“软件测试 面试 python”高频是因为Agent调试极度依赖可复现的测试闭环。考法用户投诉“Agent说查不到我的订单但我明明下单成功了。”你如何定位问题请列出完整排查路径并说明每步需要什么日志字段。标准排查链Trace ID定位从用户ID查到本次会话的唯一trace_idSpan分析在Jaeger中查看该trace的所有Span重点关注tool_order_querySpan的status_code和error_messageInput溯源检查tool_order_query的输入参数order_id是否与用户提供的订单号一致常见坑前端传参时丢了最后一位下游验证用同样的order_id直接调用订单服务API确认服务端是否存在排除Agent逻辑问题LLM上下文检查回放该次LLM调用的完整Prompt确认是否因上下文过长导致order_id被截断。必须的日志字段每个Span必须包含trace_id,span_id,parent_span_id,service_name,operation_name,start_time,duration_ms,status_code,error_message,input_hash输入参数的SHA256output_hash输出的SHA256。没有input_hash就无法做精准重放。我们线上用的Log Schema{ trace_id: 0xabc123..., span_id: 0xdef456..., service: agent-core, operation: llm_invoke, input_hash: sha256:..., output_hash: sha256:..., model: gpt-4-turbo, input_tokens: 1200, output_tokens: 350, latency_ms: 2340, status: success }这个Schema让我们能在1分钟内从千万级日志中精准定位任意一次失败调用并一键重放。2.8 模块八安全与合规不是合规文档是防御编程“oracle ebs mrp面试”“hcip-datacom题库”等词混入暗示面试官会从企业级系统集成视角考安全。典型问题你的Agent要接入客户ERP系统Oracle EBS如何设计认证授权要求1不存储客户ERP密码2支持按角色控制数据访问范围3审计所有ERP数据读取操作。答案必须体现零信任架构OAuth2.0 Device Code FlowAgent不接触密码用户用手机扫码授权获得短期Access TokenRBAC动态映射ERP中的角色如“采购员”映射到Agent的Permission Set如[read:po, write:po]每次调用前检查Permission审计日志脱敏所有ERP读取操作记录user_id,erp_role,accessed_table,row_count,timestamp但不记录具体数据内容防止日志泄露敏感信息。最致命的坑很多候选人说“用API Key”但被追问“API Key泄露怎么办”就哑火。正确答案是API Key必须绑定IP白名单Referer校验QPS限制且每7天自动轮换。我们线上Key轮换用Kubernetes CronJob Vault完全自动化。安全红线清单风险点我们的防护措施验证方式Prompt注入所有用户输入经HTML实体编码SQL关键字过滤每日渗透测试数据越权每次Tool调用前Runtime校验user_role与tool_scope匹配单元测试覆盖率100%Token泄露Access Token加密存储内存中明文存活5分钟内存dump审计日志泄露敏感字段如身份证号在日志采集层自动掩码日志抽样审计这张表是我们安全团队每月review的基线面试时拿出来比背100条“不要硬编码密码”有用得多。3. 题库使用指南如何把90%考点转化为你的实战资本3.1 别刷题要建“能力仪表盘”拿到题库第一件事不是打开编辑器写代码而是建立自己的能力仪表盘。用Excel或Notion创建一张表列是上述8大模块行是你的掌握程度0-5分每格填具体证据模块掌握度证据必须具体意图理解3分能手动画出电商场景的意图树但没做过多跳意图的AB测试工具沙箱2分了解JWT原理但没实现过动态Token注入状态管理4分在个人项目中用Redis Streams实现了版本化状态但没压测过10K QPS.........为什么有效因为90%的候选人败在“虚假熟练”——以为自己懂RAG其实只会调用LlamaIndex的默认API以为自己懂状态管理其实只用过st.session_state。仪表盘逼你用可验证的行为定义掌握度而不是模糊的自我感觉。我的实操方法对每个模块找一个最小可行项目MVP来验证。比如“工具沙箱”模块MVP就是用Python写一个安全的计算器Tool用户说“计算11”Agent调用calc(1,1)但必须阻止calc(__import__(os).system(rm -rf /))。这个MVP做完你才算真正理解了沙箱的本质。3.2 高频考点的“三阶学习法”针对题库里的每一个考点用“三阶法”深挖避免浅层记忆第一阶What现象记住考点表面问什么。例如“RAG和Agent的区别”表面是概念对比。第二阶Why根因追问为什么面试官要考这个因为他在筛选“能否区分数据增强和行为编排”。RAG是把知识塞进Context让LLM读Agent是让LLM决定要不要读、读哪部分、读完后做什么。这个区别决定了系统架构——RAG适合问答Agent适合工作流。第三阶How落地设计一个可运行的Demo。比如实现一个“RAGAgent混合体”用户问“XX产品去年销量如何”Agent先用RAG查财报PDF再用Tool调用数据库验证数据一致性最后生成带来源标注的报告。这个Demo必须包含1RAG的Chunking策略按章节切分2Agent的Tool选择逻辑当RAG置信度0.8时触发DB查询3结果融合算法加权平均RAG和DB结果。我的教训曾有个候选人把“RAG vs Agent”背得滚瓜烂熟但当我让他现场写一个RAG检索结果去重的Python函数时他卡了5分钟。这说明第二阶没走完——他没思考过“为什么RAG需要去重因为不同Chunk可能重复提及同一事实”。3.3 面试现场的“反向提问”技巧当面试官问完一个问题别急着答。先用“反向提问”确认需求这能瞬间拉开差距如果问“如何设计Agent的状态管理”别急着说Redis。先问“请问这个Agent的典型Session长度是多久是单用户高频交互还是多用户低频长会话对一致性要求是强一致还是最终一致”这个问题表明你理解状态设计没有银弹必须根据SLA定制。短Session5分钟用内存Map足够长Session24小时必须用持久化存储强一致金融用Raft最终一致社交用CRDT。如果问“如何优化Token成本”先问“当前成本瓶颈在输入侧Prompt太长还是输出侧LLM生成冗余是否有监控数据支持”这暴露了你的工程思维优化必须基于数据而不是拍脑袋。实战效果我用这个技巧在3次面试中把技术面变成了架构讨论。当面试官开始认真回答我的问题时他就已经把你当同事看了。3.4 题库之外的“第9模块”业务理解力题库覆盖90%技术考点但剩下的10%是决定Offer的关键——业务理解力。面试官会突然抛出一个非技术问题“如果让你为一家社区医院设计AI分诊Agent你会优先解决哪三个痛点为什么”顶级回答必须体现场景洞察社区医院医生少、患者多、老年用户占比高所以优先做“语音输入方言识别”降低使用门槛、“症状-科室映射”缓解医生压力、“复诊提醒”提升随访率数据现实不提“接入全市医疗大数据”因为社区医院连电子病历系统都没普及务实方案是对接现有HIS系统的有限APIROI意识每个功能都要算账比如“语音输入”能减少30%的挂号时间相当于每天多接诊15人年增收XX万。这个模块无法刷题只能靠“泡业务”。我的建议每周花2小时去真实的业务场景观察。比如去社区医院蹲点看老人怎么挂号去电商客服听录音记下用户最常问的10个问题。这些一手信息比100道题库都珍贵。4. 常见问题与踩坑实录来自7场真实面试的血泪总结4.1 “我用LangChain/LlamaIndex做过项目”——为什么这句是减分项问题现象90%的候选人开场就强调“我用LangChain做了XX”但被追问细节就露馅。真实案例候选人说“用LangChain做了客服Agent”面试官问“LangChain的AgentExecutor如何处理Tool调用失败默认重试几次超时时间多少你能改源码吗”候选人支吾“好像是默认重试……超时没改过……源码没看过。”根因分析把框架当黑盒缺乏对底层机制的理解。LangChain的AgentExecutor默认重试3次超时30秒但生产环境必须根据Tool SLA调整——支付Tool超时设为5秒天气Tool可设为10秒。避坑方案不说“我用XX框架”改说“我基于LangChain的AgentExecutor重写了run方法增加了熔断逻辑”准备一份framework_customization.md文档记录你修改过的每一处源码附上GitHub Gist链接对每个用过的框架至少读过其核心类的源码如LangChain的BaseTool、AgentExecutor。4.2 “我调通了RAG”——为什么这证明不了你的能力问题现象候选人演示一个RAG Demo能回答“苹果公司CEO是谁”就认为掌握了RAG。真实案例面试官问“如果用户问‘苹果公司2023年Q3营收比Q2增长了多少’你的RAG能回答吗”候选人愣住“啊这需要计算……RAG只能查原文……”根因分析混淆了“检索”和“推理”。RAG擅长查事实但不擅长数学计算、逻辑推理、跨文档关联。真正的RAG工程师必须设计混合架构RAG查原始数据 → LLM做计算 → Tool验证结果。避坑方案RAG项目必须包含“计算型Query”测试集如增长率、差额、排名在Demo中展示“RAGCalculator Tool”流水线用Python实现一个安全计算器准备一份《RAG能力边界说明书》明确列出什么能做、什么不能做、什么需要扩展。4.3 “我熟悉Python/TypeScript”——为什么这不够问题现象候选人强调语言熟练但写不出生产级代码。真实案例让用Python写一个线程安全的LRU Cache候选人用lru_cache面试官问“lru_cache在多线程下安全吗为什么如果要支持TTL怎么改”候选人答不上。根因分析把语言当工具没理解其运行时特性。Python的lru_cache不是线程安全的因为内部用dict存储而dict操作在CPython中不是原子的。避坑方案对每门语言掌握其“生产级特性”Python的threading.Lock、concurrent.futuresTypeScript的strictNullChecks、noImplicitAnyJava的CompletableFuture、StampedLock所有代码Demo必须加上单元测试如用pytest测Cache的并发安全性准备一个“语言陷阱清单”记录你踩过的坑如Python的list.append()在多线程下安全但list [1]不安全。4.4 “我了解LLM原理”——为什么这可能是危险信号问题现象候选人滔滔不绝讲Transformer、Attention但被问“如何让LLM少犯幻觉”就转向Prompt技巧。真实案例面试官问“如果LLM在生成财报摘要时把‘净利润增长5%’错写成‘增长50%’你的系统如何拦截”候选人答“用更好的Prompt加‘请严格按原文生成’。”根因分析把LLM当神忽视工程化防御。Prompt无法100%防止幻觉必须用“LLM规则Tool”的三重校验。避坑方案所有LLM输出必须经过结构化校验如2.5节的ConsistencyChecker