2026年AI趋势前瞻：从提示工程到上下文工程
本文探讨了2026年AI应用模式的根本转变。核心观点是从“提示工程”转向“上下文工程”，AI不再仅仅是聊天对象，而是构建工作环境的基础设施。文章详细论述了代理式编码（如Claude Code）、开源代理框架的成熟（如OpenClaw）、以及类似Karpathy倡导的复合型知识库系统，指出拥有持久且智能的上下文层将成为未来的核心竞争力。
相关文档
为什么 Agent 自我学习不能靠实时微调参数？Claude Code 的 AutoDream 是如何整理记忆的？
文章解释了 Agent 的自我学习不能依靠推理时实时微调参数，原因在于算力成本极高且会导致灾难性遗忘。真正的经验积累靠上下文工程搭建的外挂认知系统，分为三层：执行后的反思复盘提炼经验、经验的持久归档（如 Claude Code 写入 CLAUDE.md 和 memory 目录、Codex 写入 SQLite）、动态检索注入（Claude Code 的极简索引与 OpenClaw 的向量化混合检索）。此外介绍了 Claude Code 的 AutoDream 机制，模拟人类做梦时的记忆整合，在后台空闲时扫描会话日志、合并重复经验、淘汰过时策略，保持记忆库精炼，从而让 Agent 持续进化且不被冗余记录拖垮。
Graph Engineering：为普通人打造AI可读的知识图谱
本文介绍“图工程”（Graph Engineering）概念，即通过构建文件间的连接关系，让AI系统能够有效访问和利用知识。作者以自身内容系统为例，指出78%的文档因缺乏指向而无法被AI或新成员发现。他提出用Claude Code生成MAP.md文件，绘制文件夹内文件的关系图，并分三步操作：绘制地图、解读结果、优化结构。文章强调文件夹结构应反映业务划分，而非照搬模板，最终实现团队共享和自动化更新。
Dissecting over 1,500 company brains
作者基于帮助团队构建和维护超过1500个公司知识库的经验，总结了七条核心经验：1) 知识库应为AI Agent而非人类设计，让Agent自己重组信息结构；2) 通过MCP和API连接CRM、数据库等外部数据源与知识库本身同等重要；3) 让团队摆脱聊天界面，使用Claude Code、Codex、Cursor等能真正执行工作的工具；4) Notion等外部知识库因更新与工作脱节而失败，知识库必须内嵌于Agent工作流中；5) 除保存成果外，还要记录工作过程——提示词、被否决的方案和判断过程，这些是未来训练Agent的关键数据；6) 共享Slack Agent模式效果不佳；7) 知识库不应绑定单一界面，应实现一个大脑、多个接口。
Stop letting Claude Code forget your project overnight
本文介绍了如何解决 Claude Code 每天重置记忆的问题。通过 Andrej Karpathy 提出的方案，利用 raw 和 wiki 文件夹构建持久化的知识库，将 LLM 视为编译器，将原始素材编译为结构化的 Wiki。文章详细对比了 Wiki 与 RAG 的区别，并提供了基于 Obsidian 和 Claude Code 的自动化配置流程及 Hooks 脚本。
Stop letting Claude Code forget your project overnight
本文介绍了一种利用持久化 Wiki 解决 Claude Code 上下文遗忘问题的方法。作者基于 Andrej Karpathy 的思路，阐述了通过构建 'raw' 和 'wiki' 文件夹结构，结合编译器原理，将项目知识固化为可索引的 Markdown 文件，从而避免重复消耗 Token 和时间。文章还详细介绍了 Obsidian 的配置、自动化 Hooks（如 session-start/end）的集成，以及 Wiki 与 RAG 在不同数据规模下的优劣对比，为个人开发者提供了一套高效的知识管理方案。
Karpathy 的 LLM Wiki 改造版：打造更实用的 AI 个人知识库
本文针对 Andrej Karpathy 提出的 LLM Wiki 方案，结合作者自身的 Obsidian + OpenClaw + Claude Code 实践经验进行了优化。作者提出了从三层架构升级为五层架构（增加行动层与产出层），并强调人工确认机制，避免 AI 自动分类的偏差。文章详细介绍了入库、查询和健康检查的具体流程，分享了构建个人知识库的原则，旨在实现知识积累与内容产出的高效闭环。
每个人都有 AI 助手之后，团队还需要一个团队助理
文章探讨个人 AI 助手普及后团队协作面临的新问题：每人拥有 AI 不等于团队更聪明，因为各自 AI 上下文分散。作者引入 Team OS（团队操作系统）概念，将其抽象为 Context、Instructions、Skills、Connections、Governance 五类能力，并以 DoorDash 等团队实践为例，说明如何用共享 Repo、PR 审核机制建设团队助理。文章强调团队知识不再必须经由 PM 中转，AI 能力正在从个人资产转变为团队资产，建议从真实场景小范围起步，让团队助理从实际工作中生长出来。
How to Write a CLAUDE.md for Your Obsidian Vault (Full Course)
本文是一篇完整教程，讲解如何为 Obsidian 笔记库编写 CLAUDE.md 文件，让 Claude Code 在管理个人知识库时表现稳定可控。作者指出用户直接让 Claude 整理笔记常导致文件被重命名、日志被改写等问题，根源在于 Claude 不了解用户的组织方式。教程逐模块介绍了 CLAUDE.md 的 7 个必备部分：个人身份与库的用途、文件夹结构说明、笔记写作规范、安全规则（禁止删除、批量操作需确认、重命名时更新链接）、回答偏好及当前工作重点，并提供了完整模板，适用于写作者、创业者、学生和研究者。
Agent 高频题 03. 为什么要多 Agent：怎么拆、怎么通信、结果谁汇总
本文是 Agent 面试高频题详解第 3 题，围绕多 Agent 架构展开。作者结合 50 位作者、63 场面试的面经，系统梳理了六个追问方向：要不要拆、怎么拆、怎么通信、结果谁汇总等。文章指出单 Agent 在上下文膨胀、工具过多、提示词分支复杂、无法并行四方面会卡住；同时多 Agent 有 token 成本（约为普通对话 15 倍）、协调开销、信息丢失和错误传播等代价。文中总结了主从、流水线、并行分片、执行加审查、按意图转交五种结构，以及上下文、工具权限、可验收三类拆分边界，并对比 Skill、MCP、Workflow、SubAgent 等概念的适用场景，最后给出通信方式与面试应答要点。
用 magpie + Kiro 订阅，在 Claude Code 中稳定使用 Claude Opus 5.5
文章介绍了通过 magpie 本地网关与 Kiro 订阅，在 Claude Code 和 Claude Desktop 中使用 Claude Opus 5.5 的方案。Kiro 是亚马逊的 Coding Agent 产品，作者利用 magpie 插件将 Kiro 订阅中的 Claude 模型反代给 Claude Code，省去单独购买 Anthropic API 额度。文章详解了技术原理（请求经 magpie 网关和 Kiro Auth 插件转发）、安装配置步骤（Kiro 付费计划、插件安装、模型选择），并说明如何通过路由记录、订阅用量和工具调用验证模型真实性。最后提醒账号政策风险、额度消耗、数据安全和兼容性等注意事项。
yetone 的魔法：magpie 是怎么让 AI 自己维护项目的
本文分析了 yetone 维护的 magpie 项目（本地 LLM 网关）如何实现全 AI 自动化开发：19 天内产生 2,862 个 commit 和 1,204 个版本。核心机制是两份文档——AGENTS.md 作为路由表指导 agent 查阅规范，LESSONS.md 作为'错题本'，由 agent 每晚复盘当天 commit，记录返工、误合并、验证不足等问题；同一教训在 3 个不同日子出现即升级为硬规则。项目还设有严格的 PR 验收标准（回退测试、真实使用验证、明示未跑检查），人类只负责产品决策、安全闸门和方向把控。作者认为这套'事不过三'的自我进化机制值得借鉴。
12 Agentic Harness Patterns From Claude Code
文章总结了 Claude Code 中十二种可复用的代理 Harness 设计模式，分为四大类：记忆与上下文（持久指令文件、范围化上下文组装、分层记忆、空闲整理、渐进式上下文压缩）、工作流与编排（探索-计划-执行循环、上下文隔离子代理、分叉-合并并行）、工具与权限（渐进式工具扩展、命令风险分类、单一职责工具设计）以及自动化（确定性生命周期钩子）。作者强调这些是架构层面的决策而非临时提示技巧，即使模型能力提升仍具价值。
