上下文工程（01）：从 Prompt 到 Context 的范式转移
《AI Agent 开发》系列 30 篇讲的是"怎么把 Agent 搭起来"：工具调用、RAG、记忆、规划，零件一一到位。但真把 Agent 放进生产环境跑长任务，问题就来了——跑着跑着开始"失忆"，重复犯过的错，忽略早…
72
上下文工程
AI 开发 · 共 18 篇 · 按发布时间正序排列
从 Prompt 到 Context 的范式转移：压缩、缓存、子代理与记忆分层 18 篇
上下文工程（02）：token、注意力与上下文腐烂
上一篇《上下文工程全景》把结论立在了范式层：上下文工程的核心，是把模型的上下文窗口当作稀缺资源来经营。但"经营"的前提是先懂账——窗口里装的到底是什么、按什么单位计价、为什么塞得越多效果反而越差。这一篇从范式下钻到物理层…
76
上下文工程（03）：系统提示的信息架构设计
上篇解剖上下文窗口时留了一个尾巴：窗口里这么多内容，到底哪一块对模型行为的塑造力最强？答案朴素得近乎无聊——系统提示（system prompt）。用户消息一轮一换，工具结果用完即弃，检索片段随问题变化，只有系统提示从第…
73
上下文工程（04）：给上下文做财务规划
上下文工程系列前三篇讲的都是"往上下文里放什么"：窗口的物理极限、token 的计量方式、系统提示的信息架构。这一篇换一个视角——不先问放什么，先问放得起多少。Agent 的每一轮请求都是一张账单：system 提示、工…
90
上下文工程（05）：上下文压缩（Compaction）实战
跑过长会话 Agent 的人都见过状态栏上那行 "Context left until autocompact: 32%"。一个排查了 40 分钟的 bug，历史消息里堆满了文件内容、命令输出和试错的工具调用，上下文窗口…
109
上下文工程（06）：Prompt Caching 的成本反直觉
第 5 篇/post/1592讲 compaction 时，所有算式都建立在一个隐含前提上：token 越少越省钱。这个前提在 2026 年要打折扣——主流 API 的 Prompt Caching（提示词缓存）把"重复…
72
上下文工程（07）：结构化笔记（Note-Taking）模式
跑过长任务的 Agent 都经历过"失忆三连"：追问三小时前定下的口径，它翻不出来；压缩刚过，再问某个关键路径，它一脸茫然；会话重启，一切归零从头再来。对话历史看起来是记忆，其实是块易失介质——会被压缩、会腐烂、会随会话…
105
上下文工程（08）：输出裁剪与清理策略
《上下文工程》系列前几篇反复点名同一个嫌疑人：工具结果。第 2 篇/post/1589的实测账本里，24 条日志 JSON 组成的工具结果吃掉了 73% 的窗口；第 4 篇/post/1591的预算拆账又把它确认为单轮成…
125
上下文工程（09）：子代理架构与上下文隔离
主 Agent 回答"这个接口的超时重试在哪实现"要付出什么代价？grep 三个关键词命中 800 行，顺着命中读了 20 个文件，再 grep 一轮确认调用方——最终答案是 200 token 的一句话，过程却烧掉近 …
84
上下文工程（10）：RAG 信息的注入策略
RAG（RetrievalAugmented Generation，检索增强生成）链路里最容易被高估的一环是检索，最容易被低估的一环是注入。Agent 系列第 14～18 篇用五篇篇幅讲怎么把资料捞回来——切块、嵌入、混…
85
上下文工程（11）：短期、长期与工作记忆
给 Agent 补记忆的零件，这个系列已经攒了不少：第 5 篇/post/1592的 compaction 教会它压缩历史，第 7 篇/post/1594的文件笔记教会它记本子，《AI Agent 开发》系列第 23 篇…
84
上下文工程（12）：Claude Code 的实践
让 Agent 修一个函数，它能径直扎进你五年没敢动的祖传模块；让它排查一个偶发 bug，它 grep 两下就锁定病灶。这类体验的背后是同一个问题：百万行代码库里，这一轮该让模型看到哪几百行？代码是上下文工程最苛刻的场景…
84
上下文工程（13）：100 万 token 不是免费午餐
系列前 12 篇都在教同一件事：把窗口当稀缺资源省着用——预算、压缩、缓存、子代理、检索注入，招招都是"少装"。但 2026 年的价目表很容易让人动摇：GPT6 Astra 窗口 1.05M，Gemini 3 Pro 与…
90
上下文工程（14）：命中率的经济学
第 6 篇/post/1593把缓存与压缩的取舍算成了一笔战术账：命中读取只要 0.1 倍输入价，而压缩改写历史会把这笔折扣亲手作废。那篇的视角是单次决策——这一轮压还是不压。这一篇把镜头拉远：当一个系统每天跑几万轮 A…
93
上下文工程（15）：怎么知道注入的内容有用
《上下文工程》系列的前 14 篇都在做同一件事：设计上下文——预算怎么分配、历史怎么压缩、检索结果怎么注入、工具输出怎么治理。每篇结尾其实都悬着同一个问题：改完之后，怎么知道真的有效？多数团队的答案是"看模型回答好不好"…
65
上下文工程（16）：注入攻击面与内容过滤
上下文工程讨论到现在，一直在回答"往窗口里放什么"：检索结果要标注来源，工具结果要裁剪，记忆要分层注入。这一篇换个问法——放进来的每一段内容，是否可能是别人递进来的刀？《AI Agent 开发》系列第 28 篇/post…
64
上下文工程（17）：给 Agent 系列的 RAG Agent 做上下文优化
《上下文工程》系列前 16 篇各自开各的药方：预算、压缩、缓存、工具结果治理、注入纪律、评测口径。这一篇把病人请进来——优化对象是《AI Agent 开发》系列第 17 篇/post/1564搭起来的 Agentic R…
74
上下文工程（18）：总结与决策框架
《上下文工程》系列写到第 18 篇/post/1605，收官。前 17 篇按"懂账 → 技术 → 评测"的顺序层层推进，每篇解决一个专门问题；但真到线上排障时，没有人按系列顺序翻文章——你手里只有一个症状：窗口爆了、账单…
85