上下文工程

传统提示工程（菜单点菜）

• 本质：用户用自然语言描述需求（如“写一首春天的诗”）
• 局限：像在陌生餐厅点菜，依赖厨师（LLM）的理解能力

上下文工程（仪器组装）

• 本质：主动构建信息环境，让LLM在准确数据场中运行
• 核心组件：
  • RAG → 实时知识库（传感器）
  • 用户记忆 → 状态缓存（持续校准）
  • 工具API → 外部设备接口（如计算器）
  • 多模态数据 → 跨介质输入（图像/表格等）

类比：操作微芯片焊接机时，工程师需精确控制温度曲线（环境数据）、焊料供给（知识补充）、历史记录（操作日志）才能成功焊接

CO-STAR 框架是一种可以方便用于设计 prompt 结构的模板，这是新加坡政府科技局的数据科学与 AI 团队的创意成果。该模板考虑了会影响 LLM 响应的有效性和相关性的方方面面，从而有助于得到更优的响应。

• ( C ) 上下文（Context）：提供与任务有关的背景信息。这有助于 LLM 理解正在讨论的具体场景，从而确保其响应是相关的。
• ( O ) 目标（Objective）：定义你希望 LLM 执行的任务。明晰目标有助于 LLM 将自己响应重点放在完成具体任务上。
• ( S ) 风格（Style）：指定你希望 LLM 使用的写作风格。这可能是一位具体名人的写作风格，也可以是某种职业专家（比如商业分析师或 CEO）的风格。这能引导 LLM 使用符合你需求的方式和词语给出响应。
• ( T ) 语气（Tone）：设定响应的态度。这能确保 LLM 的响应符合所需的情感或情绪上下文，比如正式、幽默、善解人意等。
• ( A ) 受众（Audience）：确定响应的目标受众。针对具体受众（比如领域专家、初学者、孩童）定制 LLM 的响应，确保其在你所需的上下文中是适当的和可被理解的。
• ( R ) 响应（Response）：提供响应的格式。这能确保 LLM 输出你的下游任务所需的格式，比如列表、JSON、专业报告等。对于大多数通过程序化方法将 LLM 响应用于下游任务的 LLM 应用而言，理想的输出格式是 JSON。

技术难点拆解：为什么这是科学？

精确信息配比公式

$$\text{有效上下文}=\underset{\text{1\%}}{\underbrace{\text{核心任务指令}}}+\underset{\text{40\%}}{\underbrace{\text{RAG结果}}}+\underset{\text{10\%}}{\underbrace{\text{工具参数}}}+\underset{\text{30\%}}{\underbrace{\text{状态记忆}}}+\underset{\text{19\%}}{\underbrace{\text{安全护栏}}}$$

• 案例：医疗诊断系统需包含：

context = ["任务：基于症状诊断疾病，输出ICD编码",  # 核心指令retrieve("患者病历：咳嗽3周"),           # RAG结果"工具说明：get_icd_code() 需传递症状列表", # 工具调用规范"历史：上次误诊因忽视吸烟史",             # 记忆校准"安全限制：不得建议未批准药品<guardrail>"  # 安全约束
]

动态压缩技术（解决信息过载）

• 技术方案：

  方法	原理	压缩率
  滑动窗口	保留最近N条对话	50-70%
  语义摘要	GPT生成关键点梗概	80%↑
  向量过滤	余弦相似度筛除低关联内容	60%

工业级实践：DeepSeek系统用分层压缩——近期对话原文存储，3天前对话转向量索引

艺术性体现：LLM的“行为心理学”

▎隐式引导技巧

• 规避负面行为：
  • 禁止说： “作为AI我无法...” ➔ 改为 “我们可通过查询FDA数据库解决此问题”
• 强化合作性：
  • 注入协作痕迹：“参考用户上周建议，本次将优先考虑成本因素”

多代理协同设计

实战案例：摩根士丹利财富管理系统部署7个专项Agent分别处理税务/法规/市场数据

应用技术栈全景

关键模块说明

组件	作用	代表工具
上下文路由	分配任务到合适模型	LangChain RAGAs
记忆管理	维护用户状态历史	LlamaIndex
工具网关	桥接外部API（数据库/计算）	Microsoft Guidance
并行计算层	同时处理多请求	vLLM

为什么“套壳论”已过时？

现代LLM应用的技术复杂度已接近操作系统：

对比维度	ChatGPT交互	工业级LLM系统
上下文构建	单次对话框	动态知识图谱（>10种信息源）
任务处理	独立问答	多步骤工作流（依赖>3个模型）
资源消耗	1-2秒/请求	并行处理100+请求/秒
安全措施	基础内容过滤	合规审计+权限控制+数据脱敏

案例：SAP供应链系统通过上下文工程压缩90%人工审核，但背后需维护：

• 15个专用微调模型
• 实时连接ERP的RAG管道
• 动态合规规则引擎

上下文工程的本质

把LLM看作CPU——上下文工程就是为其设计：
1️⃣ 精准的输入设备（多源数据清洗）
2️⃣ 高效的内存管理（状态/记忆优化）
3️⃣ 安全的执行环境（工具/规则约束）
这需要融合系统架构设计、认知心理学、信息论的跨学科能力，绝非简单“套壳”。

当别人还在研究如何让CPU听懂人话时，真正的工程师已在设计整台计算机

技术演进背景

大模型应用正经历从问答机器人向智能体系统的范式迁移。早期依赖提示工程（Prompt Engineering）优化单次交互的方式，在复杂任务中显露出根本局限——当任务涉及多步骤决策、工具调用和长时记忆时，仅靠精心设计的提问语句如同让飞行员在迷雾中盲飞。这驱动技术焦点转向上下文工程，其本质是通过动态构建信息环境，为模型配备“全景驾驶舱”。

上下文工程的核心定义

上下文工程是构建动态信息生态系统的学科，需同时解决三大问题：

1. 信息完备性：注入任务所需的全部要素
   • 基础指令、历史交互、实时数据、领域知识、工具接口
   • 工业案例：医疗诊断智能体需整合患者档案（记忆）、检验报告（实时数据）、诊疗指南（知识库）、药品数据库（工具）
2. 结构可解析性：遵循机器可读的格式化表达
   • 采用YAML/JSON-LD等结构化语言替代自然语言描述
   • 关键设计：错误信息模板化（如{error_code}:{cause}比散文描述更有效）
3. 系统实时性：建立动态响应管道
   • 上下文窗口需在200ms内完成：记忆检索→工具调用→数据注入→格式优化

这要求工程师具备系统架构师思维，如同设计实时操作系统般构建信息流。

与传统提示工程的根本差异

提示工程追求“如何问得更好”，上下文工程解决“提供什么信息”。二者差异呈现在三个维度：

• 信息密度比：提示工程每token信息含量≤0.3bit（含大量修饰词），上下文工程可达2.7bit（结构化数据）
• 失败归因路径：
  • 提示工程失败→调整问题表述
  • 上下文工程失败→检查记忆检索覆盖率/工具API可用性/数据新鲜度
• 技术栈深度：
  • 提示工程依赖文本模板
  • 上下文工程需掌握：向量数据库索引优化、API网关路由、流式数据处理

典型案例对比：早期电商客服优化“请描述退货问题”提示词（提示工程），现代方案直接注入订单历史+物流状态+退改规则（上下文工程）。

技术实现框架剖析

工业级上下文引擎包含五层架构：

1. 记忆层：向量数据库实现记忆压缩
   • 采用Hierarchical Transformer将对话历史压缩至原长度15%
   • 创新点：情绪标签索引（愤怒客户对话优先缓存）
2. 工具层：原子化工具注册中心
   • 每个工具自带Schema描述：工具名: 功能 | 输入格式 | 输出示例
   • 最佳实践：工具响应自动转换为<tool_response format="markdown_table">
3. 路由层：上下文感知的分流机制
   • 基于任务复杂度选择模型：GPT-4处理多步推理，Claude-3处理长文档
4. 安全层：动态护栏机制
   • 金融场景植入实时合规检查：<compliance_check rule="SEC-2023-09">
5. 呈现层：认知负荷优化
   • 采用信息金字塔结构：结论→关键数据→原始证据

# 上下文引擎伪代码示例
def build_context(task, user):# 1. 装载基础任务框架ctx = TaskFramework(task) # 2. 注入个性化记忆ctx.inject(MemoryDB.query(user, task, top_k=3, recency_weight=0.7))# 3. 执行工具调用链if needs_calculation(task):ctx.inject(Calculator.execute(task))# 4. 动态格式优化return CognitiveOptimizer.format(ctx, style="technical_brief")

核心挑战与突破方向

当前面临三大技术瓶颈：

1. 信息过载悖论
   • 问题：注入过多上下文导致关键信息淹没
   • 解法：研发基于LLM的实时摘要器（如Google的Context Distiller）
2. 工具链协同时延
   • 问题：API调用延迟破坏思维连贯性
   • 创新：NVIDIA的推测执行引擎预生成候选响应
3. 跨会话状态管理
   • 问题：用户多轮对话中的状态漂移
   • 方案：采用强化学习维护状态向量（如DeepMind的SMT模型）

突破性案例：Salesforce服务云将客户互动压缩为四维状态向量（情绪值/问题复杂度/专业知识/紧急度），使上下文构建效率提升18倍。

未来竞争制高点

上下文工程正催生新一代技术栈：

• 上下文感知芯片：Groq LPU加速记忆检索
• 企业知识操作系统：如Microsoft Fabric实现上下文即服务
• 标准化接口协议：类似OpenTelemetry的Context Trace规范

工业界趋势表明：2025年头部AI企业将把60%研发预算投入上下文工程建设，该领域人才溢价已达薪资基准的2.3倍。当模型能力趋于同质化，上下文质量成为核心护城河——如同云计算竞争中，数据中心架构决定最终胜负。

本质重构：从交互设计到认知架构

上下文工程标志AI开发范式的根本转变：

• 过去：视LLM为“魔术盒”，专注Prompt设计
• 现在：将LLM看作“CPU”，构建完整计算机系统
  其终极目标是创建机器可感知的现实镜像——通过精准还原决策场景，释放大模型的推理潜能。这要求工程师掌握新型技能树：数据库优化、分布式系统、认知心理学，乃至人机协作哲学。当技术社区从追求提示词技巧转向构建上下文架构，我们正见证AI工程学的成年礼。

[1] Dex Horthy. 12-Factor Agents - Principles for building reliable LLM applications. (https://github.com/humanlayer/12-factor-agents/blob/main/content/brief-history-of-software.md)
[2] Dex Horthy. Context Engineering vs. Prompt Engineering: Guiding LLM Agents. (https://www.youtube.com/watch?v=mldfMWbnZTg)
[3] LangChain Team. The rise of “context engineering”. (https://blog.langchain.com/the-rise-of-context-engineering/)
[4] Hailey Joren, et al. Sufficient Context: A New Lens on Retrieval Augmented Generation Systems. (https://arxiv.org/abs/2411.06037)
[5] Walden Yan. Don’t Build Multi-Agents. (https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering)
[6] Dex Horthy. Own your context window. (https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-03-own-your-context-window.md)

https://mp.weixin.qq.com/s/nyD5Vc59FYO_ZUD8fSquJw

技术演进：从交互优化到系统重构

大模型应用的成熟期正暴露传统方法的根本局限。早期以提示工程（Prompt Engineering） 为核心的优化路径，本质是通过语言技巧引导模型行为。这如同为驾驶员提供更精确的导航指令，但当任务复杂度升级至跨时态决策（如多轮医疗诊断）、动态环境响应（如实时金融风控）时，单纯优化“如何提问”已触及天花板。Dex Horthy在《12-Factor Agents》中的实证揭示：依赖工具调用循环（Tool Calling Loop）的智能体在10-20轮交互后崩溃率超90%，核心症结在于上下文熵增——混乱的信息堆积导致模型认知过载。这标志技术焦点必然转向上下文工程，其目标是通过动态信息生态的精密控制，将模型的“认知负担”转化为“决策优势”。

核心矛盾：概率世界与确定需求的碰撞

上下文工程兴起的底层逻辑源于三重结构性矛盾：

1. 模型本质的随机性
   LLM的next-token预测机制本质是概率采样。当任务涉及长链条推理（如法律合同审查），微小概率偏差会随步骤累积引发决策漂移。Google论文《Sufficient Context》验证：即使提供充分信息，GPT-4在医疗诊断中的幻觉率仍达7.3%；而缺失关键数据时，模型却能通过模式匹配“蒙对”结果——这种不确定性无法通过提示词消除。
2. 信息管道的不可控性
   Nate Jones提出的概率性上下文（Probabilistic Context） 概念揭示：当智能体接入搜索引擎、API工具等外部系统时，返回数据质量波动极大。例如电商价格监控Agent调用爬虫API，可能因网站改版获取残缺HTML，导致后续解析失效。此类噪声在传统提示工程框架下无法根治。
3. 工程交付的可靠性需求
   企业级应用要求99.99%的稳定运行率。当智能体在10%场景崩溃（如误关闭客户工单），损失远超效率收益。这要求构建确定性信息护栏——类似飞机黑匣子的实时监控系统，在上下文熵增临界点触发干预机制。

范式跃迁：从语言技巧到系统工程

上下文工程的本质是构建机器可感知的决策沙盘，其技术框架包含三层架构革新：

1. 动态分层信息流

   • 确定性层（Deterministic Context）：工程师预设的任务指令、业务规则、格式规范。
     案例：银行风控Agent的“转账金额超5万需二次验证”规则硬编码为JSON Schema注入。
   • 概率性层（Probabilistic Context）：外部工具返回的实时数据（如天气API）、RAG检索结果。
     创新设计：为API响应添加置信度标签 <api_response confidence=0.82>，供模型加权参考。
   • 记忆层（Context Memory）：向量数据库实现的对话状态压缩。
     技术突破：采用Key-Value注意力机制，将30轮对话压缩至原长度12%且保留决策关键因子。

2. 信息密度引擎
   核心指标是单位Token有效信息量（Effective Information per Token, EIT）。工业级系统要求EIT≥1.8bit（传统提示词仅0.3-0.5bit）。实现路径包括：

   • 结构化脱糖（Structured Desugaring）：将自然语言描述转为机器友好格式

     # 低EIT：请解释用户情绪波动原因  
     # 高EIT：<sentiment_trend value="anger" delta="+43%" trigger="payment_failed">  
     

   • 增量更新协议：仅传递上下文差异量（类似Git Diff），Salesforce实测减少78%冗余Token。

3. 失效熔断机制
   当系统检测到上下文混乱指数（Chaos Index）超标时，自动触发：

   • 状态回滚：还原至最近稳定对话快照
   • 工具链路切换：例如从通用搜索引擎切至企业知识库
   • 人工接管申请：发送高优先级告警至运维台

与传统提示工程的分水岭

两者的本质差异体现在四个维度：

维度	提示工程	上下文工程
优化对象	单次输入文本	跨会话信息生态
技术栈	文本模板+关键词替换	向量DB+API网关+状态机
失败归因	模型不理解指令	信息管道失效或记忆污染
核心指标	输出相关性（ROUGE）	任务完成率（Task Completion Rate）

典型案例对比：

• 提示工程方案：通过添加“逐步思考”提升数学题解答能力，但面对动态数据（如实时股票分析）仍会崩溃。
• 上下文工程方案：构建三层信息流——
  1. 确定性层注入金融公式模板
  2. 概率性层接入Bloomberg实时行情（带数据校验）
  3. 记忆层缓存用户风险偏好
     实现97%的跨会话任务完成率。

• 糟糕提示工程 → 指令被忽略、输出混乱（依赖标点/同义词调试）
• 糟糕上下文工程 → 检索增强（RAG）失效、工具链断裂、输出泛化/误导

提示工程（Prompt Engineering）

• 定义：设计一次性指令（如“你是一位X领域专家，请完成Y任务”），通过调整措辞、格式、示例优化单次输出
• 应用场景：创意写作、单轮对话、代码生成、技术演示（如“写一条像Naval一样的推文”）
• 局限性：依赖反复调试，缺乏长期记忆和系统性支持。

上下文工程（Context Engineering）

• 定义：构建模型交互的全局框架，管理模型接收信息的内容（文档/历史记录/工具输出）、结构（组织方式）及时序（动态/静态注入）
• 关键组件：Token分配策略，系统提示设计，记忆槽位管理，工具链集成
• 应用场景：多轮对话系统、客服机器人、具备记忆的智能体、高稳定性生产环境

上下文工程核心价值：

• 稳定性：确保第1000次输出与第1次质量一致（如避免记忆泄漏）
• 抗干扰能力：防止提示被无关信息淹没（如噪声过滤）
• 规模化支持：通过动态上下文适配不同用户/任务，避免重复设计提示

工业级落地：从理论到实践

领先企业正通过三阶段路径推进上下文工程：

1. 上下文感知硬件
   Groq LPU芯片新增Context Management Unit (CMU)，专责上下文压缩/解压，使128K上下文加载延迟从秒级降至毫秒级。

2. 企业知识操作系统
   Microsoft Fabric集成：

3. 标准化协议
   新兴Context Trace协议（类似OpenTelemetry）定义：

   • 上下文版本号（Context Versioning）
   • 信息源元数据（Provenance Tracking）
   • 熵增监控指标（Entropy Metrics）

某跨国银行部署上下文工程后关键收益：

• 客服工单处理轮次从平均18轮降至9轮
• 长周期任务崩溃率从11.2%降至0.3%
• 合规风险事件减少92%

未来竞争制高点：信息效率革命

当模型能力趋于同质化，上下文质量成为决定性变量。这引发三重新型竞争：

1. 信息密度竞赛
   Anthropic的Token熵压缩算法Claude 3.5将EIT提升至2.4bit，使同等上下文窗口支持3倍复杂任务。
2. 实时性突破
   NVIDIA推测执行引擎预生成上下文分支路径，使工具调用延迟从2.1秒降至0.4秒。
3. 确定性增强
   Google的Context Distiller模块通过强化学习过滤噪声信息，将概率性上下文的失效概率降低67%。

本质重构：AI开发的范式迁移

上下文工程标志大模型应用从魔术时代迈入工程时代：

• 过去：视LLM为神秘黑盒，依赖咒语般提示词
• 现在：将LLM看作可编程CPU，通过精密信息流控释放潜能
  这要求工程师掌握新型技能树——不仅是机器学习，更需精通分布式系统（管理上下文状态）、信息论（优化EIT）、人因工程（设计认知动线）。当技术社区从追求提示词技巧转向构建上下文架构，我们正见证AI工程学的真正成熟：以确定性框架驾驭概率性智能。

https://x.com/karpathy/status/1941616674094170287

Andrej Karpathy 提出的“细菌式编程”核心就是让代码像细菌基因一样好用、好抄、好传播。

核心思想：像细菌学习写代码

Karpathy 观察到，自然界里细菌的基因（可以理解成它们的“源代码”）特别牛，让它们能在各种极端环境里活下来，还演化出各种技能。这种“牛”体现在三个特点上，也是细菌式编程的三大法则：

1. 小巧 (Small)：

   • 细菌咋做： 细菌的基因组非常精简，一点多余的东西都没有。因为复制、维护 DNA 每多一个“字母”都要耗能量，自然选择逼着它们不能“代码膨胀”。
   • 编程咋学： 你写的函数、类、模块也要尽量短小精悍，只干一件事，并且把它干好。别写又臭又长、功能混杂的“巨无霸”代码。目标： 让你的代码片段本身就很高效，没有废话。

2. 模块化 (Modular)：

   • 细菌咋做： 细菌把相关功能的基因打包成一个个叫“操纵子”的功能小包。这些包就像乐高积木一样，可以方便地插拔、组合、替换。
   • 编程咋学： 你写的代码也要有清晰的边界和接口。想象你写的某个类或者一组函数，能像一个独立的“插件”一样，被别人轻松地复制粘贴到他们的项目里去用，而不用大动干戈地改来改去。目标： 你的代码是独立的“积木块”，方便别人拿来就用。

3. 自包含 (Self-contained)：

   • 细菌咋做： 细菌有个超能力叫“水平基因转移”。简单说，就是它们能直接从别的细菌那里**“偷”** 一段有用的基因（比如抗药性基因），直接拿来用，完全不需要理解对方整个基因组是啥样。
   • 编程咋学： 你写的代码片段要尽量不依赖或少依赖你项目里其他特定的上下文、全局状态或者一堆乱七八糟的外部库。别人看到你这个函数/类，应该能几乎不修改、不引入新麻烦，就能复制粘贴到他的项目里运行并受益。目标： 你的代码是即插即用的“小工具”，别人能轻松“顺手牵羊”(yoink)。

灵魂拷问：你的代码够“细菌”吗？

Karpathy 问开发者：你写的任何一个代码片段（函数、类），能不能想象别人在不了解你整个项目、也不额外引入新依赖的情况下，直接复制粘贴走，就能立刻用上、觉得真香？你的这段代码有没有潜力成为 GitHub 上热门的分享片段 (Gist)？

如果答案是 YES，那恭喜你，你掌握了细菌式编程的精髓！这种风格能让你的代码在开源社区里像细菌基因一样自由传播、组合、进化。

对比：细菌 vs 真核生物（人类）

• 细菌式编程 (优点)： 特别擅长快速创新、做原型、传播好想法。就像细菌能快速适应新环境。
• 局限性： 难以构建极其复杂、高度协调的大型系统（比如操作系统、大型商业软件）。就像单靠细菌基因组合不出复杂器官协同工作的人体。
• 真核生物式编程 (对比)： 更像是构建一个巨大、复杂、各部分紧密耦合的单体仓库 (Monorepo)。这种结构组织性好，适合构建极其复杂的系统（就像人体），但灵活性、创新传播速度不如“细菌式”。

Karpathy 的建议：鱼与熊掌可兼得

理想状态是：在一个大的、结构化的项目框架里（真核生物骨架），尽量把里面的各个小功能、小模块写成“细菌式”的（最大化细菌DNA比例）。

• 在需要高度协调的大项目里用 Monorepo 管理。
• 但在 Monorepo 内部，努力让每个小零件都小巧、模块化、自包含，方便内部复用甚至被外部“偷走”。

现实挑战：依赖地狱

有人质疑：现在 npm/pip 这些包管理器不就是想实现模块化吗？结果搞出了恐怖的“依赖地狱”（装个小工具可能拖进来几百个依赖，版本还冲突）！

Karpathy 认为问题出在软件世界里**“写代码”的成本太低了**，没有像生物进化那样的“能量消耗”压力来自然控制代码膨胀和依赖泛滥。导致依赖像野草一样疯长，最终系统脆弱不堪。

总结一下“细菌式编程”：

1. 目标： 写出的代码像细菌基因一样自由传播、即插即用。
2. 方法： 追求短小、功能单一、模块清晰、依赖极少。
3. 好处： 促进开源创新、代码复用、快速开发。
4. 挑战： 平衡与大型复杂系统架构的需求，避免现实中的“依赖噩梦”。

简单说，就是鼓励大家多写那种“别人一看就想偷走直接用”的优质、独立的小代码块！这就是编程界的“细菌智慧”。

大语言模型（LLM）的上下文窗口有限（如32K tokens），长对话中旧信息被新输入覆盖，导致"遗忘"关键数据（如技术方案决策、用户订单详情）。上下文工程通过动态信息调度，确保LLM始终基于最相关背景生成响应，解决两大核心问题：

1. 信息丢失：早期决策/数据被挤出上下文窗口
2. 逻辑矛盾：新回答与历史结论冲突。

上下文工程是信息熵优化系统。

核心： 在有限token窗口内，通过算法（RAG/摘要/ICL）最大化关键信息密度；
目标： 让LLM的注意力机制始终聚焦高价值数据，实现信息损耗最小化与决策精准化的平衡。

上下文工程（Context Engineering）的核心在于系统化解决大语言模型（LLM）的“记忆瓶颈”问题：通过动态调度关键信息（RAG实时注入外部知识、摘要压缩历史对话提炼核心、优先级排序保留决策节点），在固定上下文窗口内实现“有限记忆空间的最优信息密度”，使LLM始终基于精准背景生成响应，彻底规避长对话中的信息丢失与逻辑矛盾，本质是信息熵优化与注意力资源的精确分配。

https://mp.weixin.qq.com/s/5TOxo1d06vlhXBlagftuOg

https://mp.weixin.qq.com/s/_v6-8Etc0VZ9ReO2asp7Yw

https://mp.weixin.qq.com/s/rQRWPkSrVZzR7-h9IKViPg

https://mp.weixin.qq.com/s/xbtgjfnpppH-NCOSdfhzeg

https://mp.weixin.qq.com/s/205_rv7OvG3W6j7YpMSFSQ

https://mp.weixin.qq.com/s/IK1PQm-FqtP3wUhuY5kMKQ

https://mp.weixin.qq.com/s/dpXEoiGzeoAI9hSl2gtBfw

https://mp.weixin.qq.com/s/lYgOtY4aXIRMFqLOoLaVxw

A Survey of Context Engineering for Large Language Models：https://arxiv.org/abs/2507.13334

https://github.com/ForceInjection/AI-fundermentals/blob/main/context/%E4%B8%8A%E4%B8%8B%E6%96%87%E5%B7%A5%E7%A8%8B%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.md

https://github.com/ForceInjection/AI-fundermentals/blob/main/context/%E4%B8%8A%E4%B8%8B%E6%96%87%E5%B7%A5%E7%A8%8B%E5%8E%9F%E7%90%86.md

https://mp.weixin.qq.com/s/9KrnTk9LwWGmsiaypu-AVw

https://mp.weixin.qq.com/s/dpXEoiGzeoAI9hSl2gtBfw

https://mp.weixin.qq.com/s/qtUqxLGe6oHZfWSea5d3pQ

https://mp.weixin.qq.com/s/qtUqxLGe6oHZfWSea5d3pQ

https://github.com/ShawhinT/llm-tool-use-ft/tree/main

https://mp.weixin.qq.com/s/eTRj7_rrVVWaoHzHdNxbgg

https://mp.weixin.qq.com/s/cD69Agd5osfElQ1niDX5Jw

https://mp.weixin.qq.com/s/27VzXwaGj3JNP148AQE_jQ

https://mp.weixin.qq.com/s/bkrTmiWmI6Hxeo6F5IliIA

https://mp.weixin.qq.com/s/2tIGSp4hi6nKJrFhWZISAA

https://mp.weixin.qq.com/s/F-GoAk-S_rZvQ0bB2YXIlw