知识工程师的兴起

agent 已经是公司知识最大的读者群之一。2026 年 7 月，在 Mintlify 托管的文档站里，agent 占到了实测网络流量的 66%。

这些 agent 背后是人：他们把阅读、并且越来越多地把行动委托给了 AI 工具。开发者让编码 agent 接 API，买家让聊天 agent 比价甚至下单，客户靠客服 agent 解决问题。

对任何负责文档、帮助内容或内部知识的人来说，职责已经超出了「把页面写对」。公司需要一套系统，让知识在人和 agent 工作的地方都保持准确、可取、一致。负责这套系统的新角色，就是知识工程师（knowledge engineer）。

不该被信任的知识的代价

2024 年，加拿大航空的聊天机器人告诉一位旅客：完成旅行后可以申请折扣票价。航空公司拒绝退款后，旅客把争议带到了不列颠哥伦比亚省民事仲裁庭。

仲裁庭裁定加航担责：航空公司要为网站上出现的所有信息负责，包括聊天机器人说的。

大多数 agent 失败不会闹上法庭。agent 查不到某产品的答案，就推荐了竞品；取到废弃的 API 参数，生成了跑不通的代码；找到两条互相冲突的政策，选了错的那条。一旦 agent 把错误信息当成权威，这个错误会被固化进生成的代码、客服回复和自动化流程，在成千上万次下游交互里复制自己。

知识质量是运维问题。

知识工作正从页面转向系统

技术写作、知识库管理、产品教育、支持团队，传统上都聚焦在生产与维护内容上。这些工作依然重要，但范围在扩大。

Decagon 的产品教育负责人 David Hou 这样描述这个转变：

「agent 是你的知识的新读者，这带来真实的产品要求：知识的形状、内容、可检索性都要变，agent 才能替用户端到端地完成有意义的任务。搭知识层不只是技术基础设施，还要人和运营基础设施——整个组织都得买账，否则真正的唯一事实源永远不会出现。」

Elastic 的内容工程师、passo.uno 的作者 Fabrizio Ferri Benedetti 把新角色叫「上下文策展人」：「一个能围绕人类与 AI 的需要、甚至只围绕 AI 的需要，编排并执行内容策略的技术写作者。」

他还说：「如果你的文档大部分由 AI 生成，但你能保证生成得好、能在 LLM 里产生预期效果，那就没问题。那些内容是人们借 AI 搭建代码大教堂的乐高积木。确保每块积木准确、对 LLM 易取，这个使命就完成了。另一个使命是帮人：人需要一套有主见的视图，看这些积木是什么、能拼出什么。」

知识工程师做什么

知识工程让公司对内使用、对外共享的信息，在人、系统和 AI agent 之间保持一致。

「成功的知识工程师把散落在组织各处的信息源连起来，变成有用的东西，」Mintlify 的知识工程师 Ethan Palm 说。「文档和公开内容对你的用户很关键，但在内部，知识散落在各个团队和工具里。你得搭出让用户和团队都信任、都准确的信息系统。」

知识工程师设计内容背后的基础设施与流程，职责包括：

• 确立权威源与明确的所有者。
• 把产品发布、代码变更、工单与反馈接到内容更新上。
• 以结构化页面、Markdown、llms.txt 索引、API 和 MCP 工具的形式发布知识。
• 定义术语、评审要求、权限与新鲜度标准。
• 度量 agent 在搜什么、哪些问题没有答案、检索在哪里失败。

工具能自动化这个环路上的一部分：Mintlify 可以向 agent 提供 Markdown、生成 llms.txt 索引、区分人类与 agent 流量。但什么是权威、如何保持准确、什么时候必须人来评审，由知识工程师决定。

agent 改变了人需要什么

人仍然是重要读者，但他们需要文档给出别的东西。

agent 受益于穷尽而结构化的信息：参数、约束、schema、流程。人需要的是理解系统为什么这样工作、该选哪条路、哪些取舍要紧。

Drew Breunig 写道：「人不需要穷尽的文档，他们需要心智模型。细节让 agent 去找。」他建议文档应该「帮人提出更好的问题、写出更好的指令」。

知识工程师一边给 agent 可靠的原料，一边帮人理解并运用它。

收益

保持知识即时可用。 更新从源头流动，而不是指望有人记得每一个下游页面；自动检测与起草也缩短了产品变更与解释之间的延迟。Coinbase 把文档更新时间从 20 多分钟压到 60 秒以内。结构化内容、清晰导航、Markdown、llms.txt 与 MCP，也让 agent 不必靠猜就能取到正确信息。

把缺口变成改进。 agent 的搜索与未答问题暴露了页面浏览分析看不到的缺口。团队能看到 agent 在哪里卡住，把缺的信息排上优先级，并度量一次更新是否真的解决了问题。

让团队分清主次。 领域专家评审提议的变更，重复的起草与分发交给自动化。写作者和工程师腾出时间投入客户体验、采用与产品质量。HubSpot 把投入文档基础设施的工程资源砍了一半，团队转向开发者增长与留存。

知识需要一个所有者

知识工程把技术写作的范围扩到内容创建与治理，并直接接进工程、设计、产品团队使用的系统。

公司可以先落实问责，再考虑要不要设新头衔。总得有人识别权威源、把更新接到源头、让知识可检索、并度量系统在哪里失败。

「成为一名出色的知识工程师需要很多种技能，」Palm 说。「别把自己限死在某一个头衔或任务清单上。先理解你和你的用户需要怎样取用知识，再找到能守护它的人。」

优势会属于这样的公司：对人和替人行动的 agent，都最快把变化变成可信、可用的知识。