Context 工程：把业务装进模型能用的形态

给正在做企业 AI 交付、发现「模型明明很聪明但输出就是不对」的人。这一页讲 Context 是什么、为什么它是 FDE（Forward Deployed Engineer，前线部署工程师）交付里最重的一站、以及怎么把它从老师傅的脑子和别人管的数据库里挖出来。

本页小目录： 一 解决什么问题｜二 两条来源｜三 要挖哪几层｜四 L2 隐性知识（判断卡）｜五 L4 数据摸底与看门人｜六 送进去的机制取舍｜七 代码库级上下文文件的类比｜八 Context 盘点清单｜九 常见误区

一、这一页解决什么问题

企业 AI 项目最常见的一句抱怨是「模型不行」。但当你真的坐到现场，绝大多数情况下模型没问题，问题是模型不知道这家公司的事：不知道 status=3 在这家 ERP 里实际含义是「已收货未退款」而不是「已完成」；不知道这条产线的温度探头装在下风口所以积灰快；不知道超过 5000 元的退货单要人工复核，而这条规矩是 2023 年一次投诉之后某位主管定的，从来没有写进任何文档。

把这些东西找出来、结构化、送进模型的可用范围，就是 Context 工程。它不是提示词技巧，是一项田野工作 + 数据工程 + 知识工程的混合活儿，也是 FDE 这个岗位区别于远程写 API 的工程师的地方。

这一页的组织方式是：先讲这个词的两条来源（Palantir 的 Ontology，和 2025 年之后 LLM 圈的 context engineering），再讲实际交付里要挖哪几层、怎么挖，最后给一份可以照着填的盘点清单。

二、两条来源

「Context」在 FDE 语境下有两条独立的源头，它们在 2025 年前后合流。理解这两条线的差别，能帮你判断一份材料在讲哪件事。

2.1 源头一：Palantir 的 Ontology

Palantir 的 Foundry 平台里有一个叫 Ontology 的东西，官方文档把它定义为「一个位于数字资产之上的、面向组织运营的层」，并称它是「组织的数字孪生（the digital twin of an organization）」，做法是把数据集和模型映射成对象类型（object types）、属性（properties）、链接类型（link types）和动作类型（action types）。[1][2]

Palantir 自己的架构文档里有两句话值得原样记住：

"The Ontology models decisions through the four-fold integration of data, logic, action, and security." （Ontology 通过数据、逻辑、行动、安全这四重整合来对决策建模。）

"The data objects, or 'nouns', … must be complemented by 'verbs' in order to model decisions; semantics must be paired with kinetics." （数据对象这些「名词」必须由「动词」补齐才能对决策建模；语义必须与动能配对。）[3]

以及一句立场声明：「Ontology 被设计用来表示一家企业复杂而相互关联的决策，而不只是数据。」[3]

为什么这条线对 FDE 重要：它给了「Context」一个比「知识库」严格得多的定义。一个知识库只要能检索到相关文档就算合格；一个 Ontology 要求你写清楚这家公司有哪些实体、实体之间怎么连、可以对它们做哪些动作、谁有权做。这四件事恰好就是一个 AI 系统要在企业里真正改变某个人的动作时必须知道的。Palantir 在 2024 年的一篇官方博客里把这套东西和 RAG 对照，提出了 Ontology Augmented Generation（OAG）的说法，主张检索的目标不应该只是文档片段，而应该是以决策为中心的对象和动作。[4]

一个常见的误传要在这里澄清：中文圈流传的「Ontology 分为 semantic / kinetic / dynamic 三层」的说法，在 Palantir 官方文档里找不到。官方用的是「四重整合（数据、逻辑、行动、安全）」以及「语义必须与动能配对」这两种表述。「三层」是第三方博客的解读，引用时应注明不是官方定义。

2.2 源头二：LLM 时代的 context engineering

2025 年年中，「context engineering」这个词在英文圈迅速取代了「prompt engineering」。两条被引用最多的原始表述：

• Shopify CEO Tobi Lütke：「我更喜欢 context engineering 这个说法而不是 prompt engineering。它更好地描述了这项核心技能：为一个任务提供全部上下文，让 LLM 有可能把它解出来，这是一门艺术。」[5]
• Andrej Karpathy 随后附议：「+1 支持 context engineering 而不是 prompt engineering。人们把 prompt 联想成日常使用中给 LLM 的简短任务描述，而在任何工业强度的 LLM 应用里，context engineering 是填充上下文窗口的精细艺术与科学。」[6]

Anthropic 的工程博客在 2025 年 9 月发表的《Effective context engineering for AI agents》给了这个概念一套可操作的原则，是目前最完整的一手论述。核心论断：

"Context is a critical but finite resource for AI agents."（上下文对 agent 是关键但有限的资源。） "Context, therefore, must be treated as a finite resource with diminishing marginal returns."（因此必须把上下文当作边际收益递减的有限资源来对待。） "good context engineering means finding the smallest possible set of high-signal tokens that maximize likelihood of desired outcome."（好的上下文工程，是找到能最大化期望结果概率的、尽可能小的高信号 token 集合。）[7]

同一篇文章给了三个具体做法，值得在交付里直接用：

做法	官方定义	在企业交付里怎么用
Compaction（压缩）	会话接近上下文窗口上限时，把内容总结后在新窗口里重新开始；「压缩的艺术在于选择保留什么、丢弃什么」	长流程 agent（比如跨几十封邮件的工单处理）必须设计压缩策略，否则会在真实数据上突然失忆
Sub-agents（子代理）	与其让一个 agent 维持整个项目的状态，不如让专门的子代理在干净的上下文窗口里处理聚焦任务	把「查数据口径」「读历史工单」「起草回复」拆成不同角色，各自只带自己需要的 context
Just-in-time retrieval（即时检索）	agent 持有引用，运行时通过工具动态把数据加载进上下文，而不是提前把所有数据都处理进去	企业数据量远超任何上下文窗口，预先灌进去既贵又噪声大；给 agent 一个能查的工具通常胜过给它一堆切片

另一条被广泛引用的一手论述来自 Cognition（Devin 的团队）2025 年 6 月的《Don't Build Multi-Agents》，它的两条原则是：

"Share context, and share full agent traces, not just individual messages."（共享上下文，而且要共享完整的 agent 轨迹，不只是单条消息。） "Actions carry implicit decisions, and conflicting decisions carry bad results."（动作携带隐含决策，冲突的决策带来糟糕的结果。）[8]

第二句对企业交付特别有用：当两个子系统各自基于不完整的上下文做了隐含假设，最后拼起来的结果会以一种很难 debug 的方式出错。这和企业里「两个部门用同一个词说不同的事」是同一种病。

LangChain 在 2025 年 7 月的文章里把上下文工程的手段归成四类——write（写出去）/ select（选进来）/ compress（压缩）/ isolate（隔离），是一个好用的分类框架。[9]

2.3 两条线合流之后

把两条线放在一起看，FDE 语境下的 Context 可以定义成一句话：

Context = 让模型在这家公司、这个岗位、这个流程上做出正确判断所需要的一切，加上把它们在正确时机送到模型面前的机制。

前半句是内容问题（要挖什么），后半句是工程问题（怎么送）。中文材料常常只讲后半句（RAG 怎么搭），而交付现场真正卡住的几乎都是前半句。

三、要挖哪几层

一个可操作的分层来自 fde-arsenal 手册的第 4 站，它把 Context 拆成四层，按「一般人挖不到的深度」排序。[10] 这个分层不是学术定义，但它有实用价值：一个 AI 项目通常死在它没挖到的最浅那一层。

层	是什么	典型症状	挖掘方法	产出物
L1 业务规则	流程真正怎么跑，包括所有例外	「文件上写的和实际干的不一样」	跟班走查 + 例外清单	规则清单（含例外与触发条件）
L2 隐性知识	老师傅脑子里的判断，没写下来	「这个只能靠经验」	边看边讲 + 案例复盘 + 让他改 AI 的答案	判断卡（现象 → 怎么判 → 动手顺序 → 什么时候这个判断是错的）
L3 组织政治	谁拍板、谁得利、谁被动了奶酪	「大家都同意，但没人推」	干系人地图 + 前任项目考古	干系人地图 + 前任项目死因
L4 数据口径	同一个词在不同系统里是不同的数	「两个报表对不上」	数据地图 + 口径追问	数据地图（含口径冲突登记）

L1 和 L3 的挖法在 需求发现与问题定义 里展开，这一页集中讲 L2 和 L4——因为这两层是最难变成「模型能用的形态」的。

四、L2：把老师傅脑子里的东西变成资产

4.1 这件事的理论名字

隐性知识（tacit knowledge）向显性知识转化，是 Nonaka 与 Takeuchi 在《The Knowledge-Creating Company》（Oxford University Press, 1995）里 SECI 模型的四个环节之一，叫 Externalization（外化）。四个环节分别是 Socialization（隐性→隐性，靠一起干活传递）、Externalization（隐性→显性，靠比喻、类比、模型把它说出来）、Combination（显性→显性，把碎片组合成体系）、Internalization（显性→隐性，学会之后变成自己的直觉）。[11]

这个三十年前的模型今天有了新用途：过去外化的目的是让下一个人学会，现在外化的目的是让模型学会。目标读者变了，格式要求也就变了——过去写成培训手册就够，现在要写成模型能检索、能引用、能据以判断的结构。

4.2 四种产出格式

实践中，把 L2 变成可用 Context 的产出物基本落在四类。这四类不是相互替代关系，一个成熟场景通常四样都要有。

（1）SOP / 规则清单——把「怎么做」写成可执行步骤，重点是把例外写进去。不带例外的 SOP 几乎没有价值，因为不带例外的部分本来就已经在系统里了。一张够用的例外清单长这样：

流程步骤	文档上怎么写	实际怎么干	例外触发条件	例外怎么处理	谁定的这个规矩	出错过吗
退货单审核	系统自动校验金额	超过 5000 元人工复核	金额 > 5000 或客户等级 = VIP	转主管，主管看客户历史	2023 年一次投诉之后王主管定的	有，去年漏了一单

经验值：任何跑了三年以上的业务流程，例外都不会少于 10 条。清单不到 10 行，说明现场跟得不够。

（2）术语表 / 口径表——把这家公司的黑话、简写、字段含义写成对照表。这一张表的价值在中文场景里被严重低估：中文行业术语、方言、简写、错别字的密度远高于英文场景，模型对它们的先验知识几乎为零。术语表既是给人看的，也要显式放进提示词和 judge 的判定规则里。

（3）案例库 / 判断卡——这是 L2 最核心的产出格式。一张判断卡的字段：

现象（他看到什么）	第一反应（判断）	依据（为什么这么判）	动手顺序	什么情况下这个判断是错的
温度报警	八成是探头脏了	这条线的探头装在下风口，积灰快	先擦探头，再看 5 分钟趋势	如果同时有振动异常，就不是探头，直接叫设备科

最后一列是这张卡的灵魂。 没有最后一列的判断卡，把一个概率判断包装成了确定结论，而这正是「AI 建议看起来很专业、实际很危险」的成因。最后一列同时也是 Eval 设计 里边界样本的最佳来源。

（4）判断规则 / 优先级规则——把多个信号如何合成一个结论写成可枚举的规则（「同时符合多类时，取优先级最高的」「出现 A 或 B 或 C 任一条件即判为 X」）。这一类规则直接成为 judge 提示词的判定条款，也是把 Eval 和 Context 缝在一起的接口。

4.3 挖法：三条按效果排序

1. 边看边讲（最好用）。跟班时，每当对方做出一个判断（不是执行一个步骤），立刻按暂停问「你刚才怎么知道要选这个的」。然后穷追：「凭经验」→「这次的经验是看到了什么」→「样子怎么不一样，另一种样子你会怎么判断」→「有没有你看错过的时候，那次怎么回事」。最后一问是金矿，它同时产出判断卡的最后一列和评估集的边界样本。
2. 案例复盘。不要问「你一般怎么判断」，拿三张真实单子放桌上——一张典型的、一张边界的、一张他当年判错过的——逐张问「这张你当时怎么处理的，为什么」。人对抽象问题的回答是编的，对具体案例的回答是真的。
3. 让他改 AI 的答案。拿 10 条模型生成的回答给老师傅，请他圈出「不像人话」的地方并用红笔改成他会说的版本。知识库的验收单位是「老师傅会怎么说」，测试集分数排在它后面。

4.4 这件事有多贵，以及一个中国的公开尝试

把隐性知识搬出来是重活。截至 2026 年，中文圈有一个值得关注的公开动作：2026 年 7 月，上海推动 13 家主体（包含上海电气、振华重工、外高桥造船、上海飞机制造等）共建「工业老师傅」数据集，攻坚十类高价值经验数据集，覆盖设备诊断、焊接缺陷判定、船舶设计校审等场景。公开报道里给的效果数字包括振华重工的焊接缺陷（气孔、咬边、未焊透）识别准确率「已达到 98% 以上」，以及上海汽轮机厂设计周期「由 30 天缩短至 14 天」。同一篇报道里也直言「工业隐性知识数字化尚无成熟通用标准」。[12]

看这类数字时建议保持两条纪律：一是问分母和口径（98% 是在什么样本集上、由谁判定的）；二是把「尚无成熟通用标准」这句话当成比效果数字更重要的信息——它说明这件事目前还在各家自己摸索的阶段，没有可以照抄的现成方案。

五、L4：数据摸底与数据看门人

5.1 数据地图：六列，不许省列

数据对象	在哪个系统 / 哪张表	谁是看门人	口径（这个字段实际是什么意思）	就绪度	拿到手日期
退货单	ERP S3F1_ZRET	财务信息科 张工	status=3 实际含义是「已收货未退款」，不是「已完成」	B	8/15

第四列是这张表存在的全部理由。 系统里的字段名和它的实际含义之间，隔着三到十年的业务变迁和无数次口头约定。

第五列「就绪度」建议用 Neil Lawrence 的 Data Readiness Levels 三档（arXiv:1705.02245，2017）[13]：

• Band C（可及性）：数据「据说存在」，但还没拿到、也没验证过；
• Band B（忠实性）：拿到了，但是生数据，字段含义、缺失、口径都没验过；
• Band A（可用性）：已经和你的具体问题对齐了，可以直接用。

这套分级在交付里的真实用途不是技术分类，是给双方一套共同语言去谈「数据到底准备好了没有」。「你们给我的数据还不能用」这句话在任何组织里说出来都得罪人；「这份数据现在在 B 档，我们一起把它推到 A」就不。

5.2 数据看门人问题

在大企业里拿到自己公司的数据是出了名的难。Nabeel Qureshi 在 Palantir 工作八年后的公开反思里写过这一点，并指出一个 8 到 12 周的试点，光拿数据就可能耗光全部时间。[14]

看门人的真实诉求往往不是技术，是地位确认。他表面在问「你要这个数据干什么、有没有审批」，实际在确认自己是不是还不可或缺。三条实践中有效的做法：

• 先给地位，再要数据。开场问「这几张表的口径，全公司还有谁懂」，而不是「我要申请 X 表的数据」。
• 谈安全，不谈数据。把对话内容换成「这批数据接出去之后的安全设计：只读账号、行级权限、审计日志、敏感字段不落地——您看还差什么」。数据进入受控环境后有行级权限和完整审计，客观上确实比散在各人 Excel 里安全，这不是话术。
• 给交换。口径文档署他的名字；把他每周手工出的那张报表自动化掉。

一个高频陷阱：业务方说「数据没问题，你先开始」。口头承诺的成本为零。数据切片没有实际到手之前，不要开始建。

六、送进去：RAG、知识库、记忆与工具的取舍

Context 挖到了，还有一个工程问题：用什么机制把它送到模型面前。截至 2026 年，主流选项和各自的适用边界大致如下。这一节只讲取舍，具体工具见 06 · 数据与平台（向量与知识库、私有化部署）与 06 · Agent 开发栈（MCP 生态与 agent 框架）。

机制	适合什么	主要代价	什么时候不要用
写进系统提示词	稳定、通用、每次都需要的规则：角色、判定优先级、术语表、红线	占用固定 token；改动需要重新评测	内容随请求变化；超过几千 token 还在增长
RAG（检索增强）	语料量大、以文档为单位、问题与文档大致一一对应	检索质量成为新的失败点；切块策略影响很大	答案需要跨多个文档做推理或聚合；语料本身口径混乱（先治理再检索）
Agentic / just-in-time 检索	语料超大、结构化系统可查、问题需要多跳	延迟和成本更高；需要设计工具与权限	单跳就能答的简单问答；无法给模型安全的查询接口
结构化对象层（Ontology 式）	需要模型对实体、关系、可执行动作有明确认识；要写回业务系统	建设成本最高	一次性的、只读的、不改变任何人动作的场景
长期记忆 / 用户画像	跨会话的偏好、历史决策	记错的东西会长期污染；需要遗忘与纠正机制	记忆内容会带来合规风险的场景
微调	风格、格式、固定输出结构；输入分布稳定	知识更新成本高；不解决「不知道公司的事」	用它来灌事实知识（这是最常见的错误用法）

三条经验判断：

1. 先治理，后检索。把口径混乱的语料塞进向量库，得到的是口径混乱的检索结果。第四层（L4）的功课偷不掉。
2. 检索质量本身要被评测。Anthropic 2024 年 9 月的 Contextual Retrieval 文章给了一个可复现的对照：把 Contextual Embeddings 和 Contextual BM25 结合，top-20 检索失败率下降 49%（5.7% → 2.9%）；再加上重排序，下降 67%（5.7% → 1.9%）。[15] 这组数字的价值不在于绝对值，在于它示范了「检索环节应该有自己的指标，并且值得单独优化」。
3. 上下文是有限资源。回到 Anthropic 那句话：目标是「尽可能小的高信号 token 集合」，不是「尽可能全」。塞得越多不等于越准。[7]

关于工具接入，Model Context Protocol（MCP）在 2024 年 11 月由 Anthropic 发布，定位是「连接 AI 助手与数据所在系统（内容仓库、业务工具、开发环境）的开放标准」[16]，此后被捐赠给 Agentic AI Foundation。[17] 对 FDE 的意义在于：企业侧的集成工作有了一个可复用的接口形态，你为某家客户封装的系统访问能力，有机会在下一家复用。

七、一个有用的类比：代码库级上下文文件

如果你想快速理解「Context 工程」在实践中长什么样，有一个人人都能上手的样本：AI 编程工具的项目级上下文文件。

• CLAUDE.md：Claude Code 的项目记忆文件。官方文档描述了分层结构——企业策略、项目记忆（./CLAUDE.md）、用户记忆（~/.claude/CLAUDE.md）、项目本地记忆（./.claude.local.md），以及一套「用户手写指令 + 根据纠正自动记录」的双轨记忆机制。[18]
• AGENTS.md：一个跨工具的开放格式，定位是「引导编码 agent 的简单开放格式」，2025 年下半年被多家工具支持。[19][20]
• Cursor Rules：分为全局规则、项目规则（.cursor/rules 目录下的 .mdc 文件，随代码版本化）等层级。[21]

这三样东西在做的事，和你在客户现场做的事结构完全一样：

编程工具里的做法	企业交付里的对应物
写下项目的架构约定与命名规范	业务术语表、字段口径表
写下「这个仓库里不要这么改」的禁令	L3 红线清单、专业边界（哪些结论必须人来下）
写下常用命令与工作流	SOP 与例外清单
文件随代码库版本化，改了要一起 review	Context 包要版本化，改了要重跑 Eval
分层：企业 / 项目 / 个人	分层：行业通用 / 这家公司 / 这个部门 / 这个人

最值得借用的一条纪律是版本化。 大多数企业项目的 Context 散在提示词、代码常量、某个人的微信聊天记录里，改了没人知道，出了问题无法回溯。把 Context 当成代码来管——有文件、有版本号、有 review、改动触发重新评测——是这个类比给的最实用的建议。

八、Context 盘点清单

这份清单用于两个时刻：进场后两周的自查，以及交接给下一个人时的验收。每一项要么打勾，要么写明「查过，没有」。

A. 业务规则（L1）

• [ ] 目标流程的完整步骤清单，包含每一步的执行人和系统
• [ ] 例外清单 ≥ 10 行，每行填了「触发条件 / 怎么处理 / 谁定的 / 出错过吗」
• [ ] 至少跟班 2 到 3 个整天，笔记里有时间戳（每个动作花了多久）
• [ ] 「变通」清单：一线在系统之外用的私人 Excel、微信群、纸条、自定顺序

B. 隐性知识（L2）

• [ ] 判断卡 ≥ 5 张，每张都填了「什么情况下这个判断是错的」
• [ ] 术语表：黑话、简写、方言、常见错别字的对照
• [ ] 判断规则：多信号合成结论的优先级与触发条件，可枚举
• [ ] 至少一轮「让老师傅改 AI 的答案」的记录（原文 + 他的红笔版本）
• [ ] 老师傅讲过的错误案例 ≥ 5 个（它们同时是评估集的边界样本）

C. 组织与边界（L3）

• [ ] 干系人地图：拍板人 / 掏钱的 / 天天用的 / 被动了奶酪的 / 数据看门人，名字写出来
• [ ] 三类决策的拍板人分别是谁：技术方案、流程变更、上线授权
• [ ] 前任项目死因（有就写，没有写「查过，没有」）
• [ ] 红线清单：哪些输出一次都不能出现（同时是 Eval 的一票否决项）
• [ ] 专业边界确认：这个场景出错的最坏后果是什么，是否需要专业方主导建模

D. 数据（L4）

• [ ] 数据地图六列填满，每张表标了 Band（A/B/C）
• [ ] 至少一批真实数据切片实际到手（不是承诺到手）
• [ ] 每个关键字段的口径写下来了，且由看门人确认过
• [ ] 数据剖面：每个字段的空值率、取值分布、异常值、时间断层
• [ ] 口径冲突登记：哪些指标在不同系统 / 不同部门有不同定义
• [ ] 权限与合规：脱敏方式、行级权限、审计日志、数据出境与留存约定

E. 工程侧（送进去的机制）

• [ ] Context 的存放形态确定了：系统提示词 / 检索库 / 结构化对象 / 工具
• [ ] Context 有版本号，改动记录在案
• [ ] 检索环节有自己的指标（如果用了 RAG）
• [ ] 上下文预算算过：一次请求大约多少 token，长会话怎么压缩
• [ ] 权限在 Context 层生效（不同用户看到的检索结果不同）
• [ ] Context 改动会触发 Eval 重跑

F. 交接

• [ ] 上述所有产出物在一个可交接的位置，不在个人电脑上
• [ ] 有一份「这份 Context 是怎么来的」的说明：访谈了谁、跟了几天、哪些结论证据薄弱
• [ ] 下一个人不找你也能改：规则文件可读、命名可懂、改了知道要跑什么

九、几个常见误区

「先把所有文档丢进向量库再说」。 这是把 L4 的功课跳过去了。口径没治理的语料检索出来仍然是打架的答案，而且更难 debug——因为你不知道模型看到的是哪一份。

「Context 是一次性工作」。 业务规则会变，口径会变，人会走。Context 需要一个更新机制和一个负责人，否则半年后系统的表现会以一种没人能解释的方式退化。上线后「不知道」的比例上升，往往是 Context 过期的第一个信号（见 Eval 设计）。

「微调能解决知识问题」。 微调擅长的是风格、格式和固定输出结构，不擅长灌事实知识——事实会变，微调不会跟着变。判断顺序建议是：提示词 → 检索 → 工具 → 最后才考虑微调。

「Context 越多越好」。 与直觉相反，也与 Anthropic 那篇文章的结论相反。上下文是有边际收益递减的有限资源，噪声会挤掉信号。[7]

「把统计规律当成领域知识」。 从历史工单里挖出「73% 的同类报警最终是 X」，不等于你理解了这个领域的失效机理。当统计上最常见的原因恰好是后果最轻的那个时，按频率排列排查顺序会把高风险分支排到后面。这类判断的建模主导权应该在领域专家手里，FDE 的工作是把它结构化地请出来。相关失败模式见 05 · 失败模式与反模式。

延伸阅读

• 需求发现与问题定义 — L1 和 L3 的具体挖法、访谈提纲
• Eval 设计 — 判断卡的最后一列如何变成边界样本；Context 改动如何触发重跑
• 交付生命周期 — Context 这一站在整条流水线里的位置与耗时
• 各家框架对照 — 不同流派对 Context 这一站的不同处理
• 05 · 干系人与数据获取 — 数据看门人怎么谈、数据到手后 48 小时的体检动作
• 06 · 数据与平台 — 向量库、知识库与私有化部署的具体选项
• 00 起点 · 术语表 — Ontology、RAG、MCP、Context 的定义
• Anthropic, "Effective context engineering for AI agents" — 目前最完整的一手论述，短，值得逐段读
• Palantir Docs, "The Ontology system" — 想搞清楚「数据语义层」这条线的人从这里开始

来源

1. Palantir, "Ontology — Overview", Palantir Docs. https://www.palantir.com/docs/foundry/ontology/overview
2. Palantir, "Ontology — Core concepts", Palantir Docs. https://www.palantir.com/docs/foundry/ontology/core-concepts
3. Palantir, "The Ontology system", Palantir Docs · Architecture Center. https://www.palantir.com/docs/foundry/architecture-center/ontology-system
4. Palantir, "Building with Palantir AIP: Data Tools for RAG/OAG", Palantir Blog, 2024-02-07. https://blog.palantir.com/building-with-palantir-aip-data-tools-for-rag-oag-b3b509c8b0f3
5. Tobi Lütke（Shopify CEO）关于 context engineering 的推文，2025 年 6 月。https://x.com/tobi/status/1935533422589399127（发布日期约 2025-06-19，由推文 ID 反推，【日期待核实】）
6. Andrej Karpathy 关于 context engineering 的推文，2025 年 6 月。https://x.com/karpathy/status/1937902205765607626（发布日期约 2025-06-25，由推文 ID 反推，【日期待核实】）
7. Anthropic, "Effective context engineering for AI agents", Anthropic Engineering, 2025-09-29. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
8. Walden Yan / Cognition, "Don't Build Multi-Agents", 2025-06-12. https://cognition.ai/blog/dont-build-multi-agents
9. LangChain, "Context Engineering for Agents", 2025-07-02. https://www.langchain.com/blog/context-engineering-for-agents
10. 任鑫（Mars），《培养旅程 · 04 真问题与 Context》，fde-arsenal（中国 FDE 手册）。https://github.com/ai-alchemy-lab/fde-arsenal
11. Nonaka, I. & Takeuchi, H., The Knowledge-Creating Company, Oxford University Press, 1995（SECI 模型）。综述可参考 https://www.sciencedirect.com/science/article/pii/S2096248717300061
12. 新浪财经，《上海共建"工业老师傅"数据集：沉淀一线隐性工艺资产，打通智造数据堵点》，2026-07-18。https://finance.sina.com.cn/tech/roll/2026-07-18/doc-iniiftix8272817.shtml
13. Neil D. Lawrence, "Data Readiness Levels", arXiv:1705.02245, 2017. https://arxiv.org/abs/1705.02245
14. Nabeel Qureshi, "Reflections on Palantir". https://nabeelqu.co/reflections-on-palantir/
15. Anthropic, "Introducing Contextual Retrieval", 2024-09-19. https://www.anthropic.com/news/contextual-retrieval
16. Anthropic, "Introducing the Model Context Protocol", 2024-11-25. https://www.anthropic.com/news/model-context-protocol
17. Anthropic, "Donating the Model Context Protocol and establishing the Agentic AI Foundation". https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
18. Anthropic, "Claude Code — Memory", Claude Docs. https://docs.claude.com/en/docs/claude-code/memory
19. AGENTS.md 官方站点. https://agents.md/
20. InfoQ, "AGENTS.md Emerges as Open Standard for AI Coding Agents", 2025-08. https://www.infoq.com/news/2025/08/agents-md/
21. Cursor, "Rules", Cursor Docs. https://cursor.com/docs/rules