菊厂员工：朋友家的孩子，上海交大毕业后进入华子年薪42万，干了一年，OPPO来挖他做芯片，直接开到56万（附Agent面试题）

有读者发来一张包浆的截图，问我是真是假。截图里的主人公上海交大毕业进了华子，年薪 42 万，干了一年被 OPPO 挖去做芯片，开到 56 万。故事的后半段更有意思，在 OPPO 干了一年，他又想回华子了。

我只能说，一旦你对华子的工作环境熟悉，是会感觉很舒服的，我身边有几个朋友都这样，根本不想去互联网卷，哪怕涨薪也不想去。

这其中的原因很简单，每一家公司都有自己的优缺点，而每一个人也都有自己的好恶。

就像有的人喜欢用 Claude Code，有的人喜欢用 Codex，还有的人喜欢用 Qoder、WorkBuddy、Kimi Code，没有对错，只有适不适合。

可能很多小伙伴还不了解华子的产品线，我帮大家调研了一下。

截止到今天，华子在 AI Agent 上已经有了自己的一条产品线，消费者能用小艺，开发者能用码道 CodeArts，企业能用智果 AgentArts，并且，华子已经把 Agent 用到网络通信、金融和制造行业。

甚至华子也开源了一系列自己的项目，其中 openJiuwen 是最值得关注的，包含了一组围绕 Agent 开发、执行、部署和应用的基础组件。

行业里也已经有拿得出手的成绩，比如说 2025 年，华为与中国电信的网络运维智能体项目获得 TM Forum 数据与 AI 创新奖；到 2026 年，又推进了 AgenticRAN、Agentic Core 和面向电信 Agent 协作的 OpenAN 项目。

如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来的硬核内容，希望你能认真读一读。

（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗发～）

content

01、记忆跑久了出现污染，有什么管理措施？

“我会先分清楚污染是怎么来的。一种是信息过时，配置已经改了，记忆里还是旧的。另一种是错误累积，Agent 把一次错误的结论写进记忆，后面的决策都建立在这个错误上。”

“错的记忆不会自己过期，写进去以后很难再被发现，所以只能在写入时拦截。长期记忆只存用户明确要求记住的稳定事实，模型自己的推测、一次性的任务、临时文件名都不存。”

“外部内容是错误信息最主要的来源。接触过网页、MCP 这类外部内容的会话，最好不自动生成记忆，外部内容里夹带的错误信息甚至恶意指令，很容易借着记忆带到下一次会话。Codex 的记忆功能就有这样一个开关，可以把用过 MCP 和联网搜索的会话排除在记忆生成之外。”

“当然了，写入门槛再高，也挡不住信息过时，写进去的时候是对的，过几个月可能就不对了。所以记忆只能当线索，行动之前先拿当前环境核实一遍。比如记忆里写着项目用 Java 17，改构建配置之前先读一遍 pom.xml，对不上就以文件为准，再提醒用户更新记忆。”

“核实时要是发现同一件事有两条说法不一样的记忆，不要静默覆盖，把两条都呈现给用户，让用户决定留哪条。”

为什么去重不能靠 embedding 相似度？

“项目用 Java 17”和“项目用 Java 21”的向量相似度非常高，按相似度去重，新事实会被当成重复内容丢掉。

相似度更适合用来发现冲突。先把数字和版本号遮掉再比，文字几乎一样、数值却不同，大概率是同一件事的新旧两个版本，这正好是该交给用户裁决的情况。

02、上下文压缩之后摘要丧失语义精确性，不压缩又膨胀，怎么权衡？

“压缩要按代价从小到大来。能保住信息的手段先用，会丢信息的摘要放在最后。”

“上下文里最占地方的往往是工具输出，一次命令执行或者整文件读取就是几千行，所以最先处理它们。大块输出写到本地文件，上下文里只留文件路径和开头一小段预览，模型需要时再按路径读回来。”

“Claude Code 对超长的命令输出就是这么处理的。这一步是可恢复的，信息没有丢，只是换了个地方放。”

“当然了，这种卸载冗余信息的做法只管得了单条特别大的输出，管不了一轮轮攒下来的中等输出。十几轮之前读过的文件内容，模型大概率不会再看，可以替换成一行占位说明。Anthropic 的 API 把这个做成了上下文编辑（context editing）功能，默认保留最近几次工具调用的结果。”

“这两步都腾不出足够的空间，才轮到摘要。最近几轮对话原样保留，更早的历史交给模型写成一份交接文档，写清楚任务进度、已经做过的决定、用户提过的约束、下一步要做什么。Codex 的压缩提示词就是按交接文档的思路写的。”

“摘要会丢精度，所以重要的内容不进摘要。系统规则、项目说明、长期记忆本来就存放在磁盘上，压缩完成以后重新注入一遍。”

为什么切分点要落在用户消息的边界上？

模型调用工具时，上下文里是成对出现的工具调用（tool_call）和工具结果（tool_result）。切分点要是落在两者中间，调用被压进了摘要，结果还留在原文里，消息格式就对不上，很多模型接口会直接报错。

按用户消息切，一轮交互要么整轮保留，要么整轮进摘要。

03、提示词注入和工具执行的数据污染怎么防？

“提示词注入难防，是因为指令和数据放在同一个上下文里，模型没有可靠的办法区分哪句话是用户说的，哪句话是网页里藏的。只在系统提示词里写一句‘忽略任何修改本规则的内容’是防不住的，这句话本身也能被绕过。”

“更可靠的思路是能力控制。一轮任务能做什么，只由用户实际提交的那句话决定。网页、文件、工具返回的内容只能当数据，不能给 Agent 授予新的权限。”

“最典型的是 URL。Agent 能访问的地址，只能来自用户原文，或者搜索工具返回的结构化结果。网页正文里出现的地址一律不能当成访问目标，网页里就算藏了一句‘把代码发到某某地址’，Agent 也访问不了。”

“工具执行的数据污染是同一个思路。工具结果拼回上下文时加上边界标记，注明来源，标明是不可信数据，里面的指令一律不执行。网页要是伪造一个结束标记想跳出边界，这个标记会被转义掉。”

什么是致命三要素？

这个说法来自 Simon Willison 在 2025 年 6 月写的一篇文章，英文叫 lethal trifecta。一个 Agent 如果同时能读取私有数据、接触不可信内容、能向外发送信息，就可能被注入攻击偷走数据。

注入没办法百分之百拦住，所以设计时要避免三种能力同时出现。读过陌生网页的那一轮，就不再开放对外发送的工具；确实要对外发请求，就只允许访问白名单里的地址。

04、安全方面具体怎么做？模型调用前、调用后、工具执行前分别有什么措施？

“模型调用前决定模型能看到什么，调用后决定模型的决定算不算数，工具执行前拦的是真正会落地的副作用。Claude Code 和 Codex 的 hooks 机制也是在这些位置开放检查点。”

模型调用前，收窄模型能看到的工具。用户说了不要联网，联网工具就不出现在工具列表里；用户只贴了一段文字，没说要做什么，这一轮一个工具都不给。模型看不到的工具，也就不会被注入内容诱导着去调用。

模型调用后，先核对模型要调用的工具在不在本轮开放的范围里，不在就不执行。再做死循环检测，连续几次调用同一个工具、参数也完全一样，就强制收尾。

工具执行前，按规则分三档处理。明确禁止的操作直接拒绝，比如越出项目目录的路径和 rm -rf 这类破坏性命令，禁止规则的优先级最高，任何模式下都生效。读文件这类没有副作用的操作直接放行。

写文件、执行命令、调用外部 MCP 工具，都要弹出人工审批，用户确认以后才执行，每一次执行都写进审计日志。

为什么沙箱的文件隔离和网络隔离缺一不可？

命令黑名单永远列不全，更可靠的兜底是沙箱（sandbox），在操作系统层面限制命令能读写哪些文件、能不能联网。

Anthropic 在 2025 年 10 月介绍 Claude Code 沙箱的文章里讲过这个道理。只有文件隔离、没有网络隔离，恶意命令可以把读到的 SSH 密钥发出去；只有网络隔离、没有文件隔离，恶意命令可以改掉沙箱依赖的配置，逃出沙箱再联网。

05、Top-K 小了召回不全，大了引入噪声，怎么解决？

“Top-K 同时管着两件事，召回多少条，最后给模型多少条，所以才会顾此失彼。我的做法是。”

“召回阶段宁多勿少。BM25 和向量检索两路并行，各自召回一个比 Top-K 大得多的候选集，再用倒数排名融合（RRF，Reciprocal Rank Fusion）把两路结果合并。RRF 只看文档在两路结果里的排名，不看原始分数，因为 BM25 和向量相似度的分数量纲不一样，直接加权再相加并不可靠。”

精排交给 rerank 模型。它把问题和候选片段拼在一起计算相关性，比向量检索准，代价是慢，所以只在融合后排名靠前的几十条上跑。

最后按 rerank 分数截断，低于阈值的丢掉，过线的最多保留 Top-K 条。问题简单，可能只有两三条；问题复杂，就多给几条。

OpenAI 的文件检索工具也是这个思路，关键词和语义两路用 RRF 融合，再用分数阈值做截断。

为什么 BM25 要单独召回？

一篇文档关键词完全匹配，向量得分却不高，在向量召回这一步就被刷掉了，后面的 BM25 根本没机会看到它。型号、错误码、配置项名称这类查询最容易出现这种情况，所以 BM25 必须作为独立的一路参与召回。

06、结构化切分好，但数据源结构不理想怎么办？

“数据源没有可靠的标题层级，就从文本本身找边界，按段落、句子、词语逐级切。先按空行切段落，段落太长就按句号切，单句还太长再分词，在词的边界上切，块和块之间留一段重叠。”

“切小了又有新问题，一块文本离开了原文就读不懂。比如某一块写着‘营收比上季度增长 3%’，没说是哪家公司、哪个季度，这一块几乎不可能被检索到。”

“解决办法是给每块补一段上下文说明。入库前让模型读一下这块所在的局部，也就是文档标题和前后相邻的内容，给每块写一两句话，说明它出自哪份文档、讲的是哪部分，再和原文一起建向量索引和 BM25 索引。展示和引用仍然只用原文，模型写的说明不会冒充原文出现在用户面前。”

“这就是 Anthropic 在 2024 年 9 月公开的上下文检索（Contextual Retrieval）。按它公布的数据，向量和 BM25 都用上上下文说明以后，检索失败率降低了 49%，再加上 rerank，降低了 67%。”

“这段说明要为每块调一次模型，成本不低，所以做成开关。还有一个更便宜的补法，把检索和返回拆开，用小块做检索，匹配更精确；命中以后把这块连同前后相邻的内容一起交给模型，上下文更完整。”

07、非结构化数据怎么实现结构化处理？

“按成本从低到高来。日期、金额、编号这类格式固定的字段，用正则和关键词定位就能提取出来，又快又准。”

“同一类文档的格式其实差不多，比如公司的合同大多出自那几份模板。人工标注几份样本，整理出结构模板，后面同类文档按模板解析。”

“规则和模板都搞不定的，再交给大模型。给模型一段文本和一个目标 Schema，比如合同的 Schema 定义了甲方、乙方、金额、期限、违约条款，模型读完直接输出 JSON。”

08、不同格式的简历怎么建成知识库做检索？

“简历的格式千差万别，但 HR 要检索的字段是固定的，学历、工作年限、城市、技能这些。所以先把格式搞定，再把字段抽出来。”

“不管原始简历是 PDF、Word 还是图片，先解析成纯文本，再让大模型按预定义的 Schema 把字段填好。”

难点在检索。HR 搜“三年以上 Java 经验，熟悉 Spring Cloud，北京”，城市和年限要精确匹配，技能却要语义匹配，熟悉 Spring Cloud 的人，简历上写的可能是微服务。

抽出来的字段要存两份。结构化字段进 Elasticsearch，用 filter 做精确筛选；技能和工作经历向量化，做语义检索。两路结果取交集。

09、分块和结构化依赖大模型，怎么保证处理结果稳定？

“格式问题交给结构化输出（Structured Outputs）。把 JSON Schema 直接传给模型接口，接口用约束解码保证输出一定符合 Schema，字段名和类型都不会跑偏，比在提示词里写‘请输出 JSON’可靠得多。OpenAI 和 Anthropic 的接口现在都支持这个能力。”

“内容稳不稳，温度帮不上太多忙。温度设成 0，推理服务批处理时的数值差异仍然会让输出不一致。Thinking Machines 在 2025 年 9 月的文章里，用同一个提示词在温度 0 下跑了 1000 次，得到了 80 种不同的结果。”

“能做的是同一份文档抽取两次，两次结果不一致的字段，说明模型自己也拿不准，直接送人工复核。剩下的按批随机抽检，哪类文档错得多，就给这类文档加几个正确的抽取样本，也就是少样本示例（few-shot）。”

10、方案怎么评估效果好不好？

“评估要把检索和生成分开看。不然回答错了，分不清是没搜到，还是搜到了没用对。”

准备一批带标准答案的问答对，每道题标注它应该命中哪些文档。检索这边看 Recall@K 和 MRR，Recall@K 看前 K 条结果里有没有需要的文档，MRR 看这篇文档排得靠不靠前。生成这边看两件事，忠实度看回答能不能在检索结果里找到依据，正确性看答案和标准答案对不对得上。

两类指标放在一起就能定位问题。检索命中了、回答却错了，问题出在提示词或者模型；检索本身就没命中，先别动模型，回头去查分块和检索。

生成质量靠谁打分？

人工判太慢，一般用大模型当评委（LLM-as-a-judge），对照标准答案和检索证据打分。评委模型有自己的偏差，2023 年提出 MT-Bench 的那篇论文就指出过，评委会偏向排在前面的答案、偏向更长的答案，也会偏向自己生成的答案。

评委打完分，还要定期抽一批让人工也判一遍，算评委和人工的一致率。一致率掉下来，说明评分标准要改，或者评委模型已经不可靠了。

11、怎么评估分块后的效果？

“分块切得不好，最典型的是一个知识点被切成了两半，检索只召回其中一块，回答就缺了一截。”

这个问题在召回率上能看出来。同一批测试问题，旧分块跑一遍，新分块跑一遍，比一比召回率和回答质量，就知道这次调整有没有用。

召回率只能说明结果，想知道问题出在哪里，还得随机抽一批分块出来看。单独拿出一块能看懂它在讲什么，说明这一块是完整的；一开头就是“它的第二个参数”这种话，说明前面的内容被切到上一块去了。

12、除了降低温度和 Prompt 约束，还有什么方法降低幻觉？

“让模型只从检索结果里找答案，检索结果里没有的信息，不允许出现在回答里。光这么要求还不够，还得让每句话都能查到出处。”

“检索回来的每个文档块都带编号，模型回答时在句末标注引用的编号，前端点编号能跳到原文件的具体页码。检索一条都没召回时，直接回答暂无相关信息。”

“引用里展示的原文，要由系统从文档里截取，不能让模型自己复述。模型复述时改几个字，意思可能就变了。Anthropic 的引用接口（Citations API）就是这么设计的，引用的原文直接从文档里抽出来，保证每条引用都指向真实存在的文字。”

13、强制标注引用来源，实际遇到过什么问题？

“碰到过模型偷懒。检索明明返回了片段，模型觉得不够贴切，直接回一句知识库暂无相关信息。后来在系统提示词里写死了，只要检索返回了片段，就必须基于片段作答，只有检索结果为零时才能说暂无。”

另一个问题是引用粒度不匹配。一个文档块里可能有好几个知识点，模型引用了整块的编号，实际只用了其中一两句，用户点开还得自己在整块里找。

我们在引用信息里加了证据摘要，从文档块里截取和回答最相关的一小段，最多 160 个字符。用户看一眼摘要，就能判断引用准不准。

14、模型出现虚空引用怎么办？

“虚空引用就是模型标了编号，但被引用的文档里根本没有这个说法。很多时候是因为模型觉得每句话都必须带引用，没有依据也要硬凑一个。”

根源既然在模型觉得非带引用不可，就先给它留退路。检索到了片段，就只回答片段能支撑的部分，片段里没覆盖到的，明确告诉用户资料里没有。

留了退路还是会有漏网的，再加一道事后校验。回答生成以后，把带引用的句子和它引用的文档块配成对，一次性交给模型判断引用能不能支撑这句话。不被支撑的引用标记为可疑，前端置灰并加上“待核实”的提示。

这道校验要多调一次模型，回答也要等它跑完才算结束，所以做成开关，对准确性要求高的场景再打开。

15、上线之后怎么看检索效果和回答效果？

“检索效果先看 rerank 过线的比例。一条都没过线的回答越来越多，说明用户的问题和知识库对不上，可能是知识库过期了，也可能是提问方式变了。”

“过线率掉下来，也可能是检索服务自己出了问题。rerank 或者 embedding 服务故障时，系统会退回更简单的检索方式，所以还要盯住降级占比，这个比例突然升高，先去查对应的服务，不用急着怀疑知识库。”

回答效果看用户行为。最直接的是追问率，回答到位的话用户一轮就解决了，追问率持续偏高，说明没答到点上。前端再放“有用”和“没用”两个按钮，收集显式反馈。

指标只能发现问题，确认问题还得靠人。每周随机抽一批对话，人工看检索有没有召回正确的文档，回答有没有如实引用，有没有幻觉。

16、产品更新后知识库怎么保鲜？

“最常见的是文档内容旧了，这种好办，靠增量更新。发了新版本文档，上传新的，删掉旧的，文档有固定发布渠道的，比如 Git 仓库，可以接 webhook 自动触发更新。”

embedding 模型换了更隐蔽，文档一个字没改，检索却越来越不准。旧模型生成的文档向量和新模型生成的查询向量不在同一个语义空间里，检索照样能跑，结果却是错的。所以每条向量都要记录是哪个模型、哪个版本生成的。

换模型不能在原索引上边删边建，重建期间新旧向量混在一起，检索结果会时好时坏。稳妥的做法是蓝绿切换，新建一个索引，用新模型把所有分块重新生成一遍向量，校验文档数和测试问题都没问题，再用 Elasticsearch 的索引别名一次性切过去。

切换时，查询用的 embedding 模型要和别名一起切。只切别名的话，查询向量还是旧模型生成的，照样对不上。旧索引先留着，出了问题把别名和模型一起切回去就是回滚。

17、项目中什么地方可能发生 OOM？

“最容易出问题的是大文件解析。几百兆的 PDF 整个读进内存，堆很容易被撑爆。”

解析要全程流式处理，常见格式用 Tika 的 SAX 解析器，基于事件一段一段地读。PDF 的渲染和 OCR 最吃内存，交给外部进程去做，JVM 只拿回提取出来的文本。

单个文件处理好了，还要防多个大文件同时解析。解析任务的并发数用信号量控制，堆内存超过 80% 就暂停 Kafka 消费，降到 70% 以下再恢复，让压力停在消息队列里。暂停和恢复用两个阈值，是为了避免内存在阈值附近波动时，消费者被反复开和关。

向量生成也一样，分完块按小批次调用 embedding 接口，拿到向量立即写入索引，不在内存里攒着。

线上再加上 -XX:+HeapDumpOnOutOfMemoryError，真出了 OOM，能拿到堆转储文件，定位是哪个对象撑爆了内存。

18、知识库有两篇冲突的文档怎么处理？

“完全相同的文件好办，上传时按文件的 MD5 去重，同一个文件不会入库两次。”

“难的是内容冲突，比如两篇文档对同一个配置项给了不同的值。新文档向量化完成以后做一次扫描，拿它的每个分块去已有文档里找最相似的几个分块。向量相似度很高的，再把两段文字里的数字、版本号、日期遮掉比一次，遮掉以后几乎一样、遮掉的值却不同，就标记为疑似冲突。”

标记以后，我不建议自动处理。按时间戳保留新的那篇看起来省事，但新上传的不一定就是对的，比如有人传了一份过期的草稿。所以冲突只进管理后台的待处理列表，由管理员决定保留新的、保留旧的，还是忽略。

这套规则只抓数字、版本号、日期这类值的冲突，“开启”和“关闭”这种文字上的矛盾，规则判断不了。规则找出来的候选，还可以再交给模型复核一遍，减少误报。

19、MinIO 上传文件讲一讲？

“我们用的是分块上传，支持断点续传。”

“客户端把文件按固定大小切块，每块带上文件的 MD5 和块序号发给服务端。服务端把块存进 MinIO，同时在 Redis 的 Bitmap 里把这一块标记为已上传，文件 MD5 做 key，块序号做 offset，查某一块传没传过就是一次 O(1) 的位运算。”

断点续传就靠这个 Bitmap。客户端上传前先查一次，传过的块直接跳过，网络断了恢复以后，只传剩下的块，不用从头开始。

所有块到齐以后，服务端调用 MinIO 的 compose 接口，按块序号在 MinIO 内部把分块拼成一个完整对象，拼完再把分块删掉。

合并完成以后，解析、分块、向量化走异步。上传服务往 Kafka 发一条消息，消费端收到以后开始处理。消费端可能重复消费，所以处理流程本身要做成幂等的，同一个文件重跑一遍，结果不变；处理失败的消息进死信队列（Dead Letter Topic），排查以后可以重新投递。

为什么每块切 5 MiB？

MinIO 兼容 S3 协议，compose 拼接和 S3 分片上传的要求一样，除了最后一块，每块至少 5 MiB。前端按 5 MiB 切块，刚好满足这个下限，服务端就能直接在 MinIO 里拼，不用先下载到磁盘再重新上传，合并时文件内容完全不经过 JVM。

ending

横看成岭侧成峰，远近高低各不同。

华子也好，OPPO 也好，每家公司、每个人的体感都不一样，去哪儿是自己的选择。

这个时代，最打动我的就是，Agent 让每一个人的能力上限都有了质变。

我们身处在非凡的时代，理所应当做出一番成就。

冲吧。