AI 资源库 · 已整理 12 项
查看与上下文管理相关的 AI 资讯、工具、Skill、工作流和开源项目。
Meta、MIT 和华盛顿大学的研究人员提出了一种叫“上下文语言模型”（CLM）的新方法。过去，语言模型的长上下文通常靠事先定好的规则来总结、压缩和检索信息，不够灵活。这次让模型自己决定怎么管理和修改上下文内容。研究人员表示，这种做法在性能和计算效率上都有明显提升。对读者来说，这意味着未来 AI 处理长对话、长文档时可能更聪明，同时更省算力，不过目前还只是研究阶段。
提供的材料未提及具体可用工具。
Patrick Debois 分享了一个观点：把 AI 编程助手用到的“上下文”（可以理解为喂给它的背景信息，比如代码库说明、规则、文档）当成代码来管理。原来上下文往往散落各处、没有测试和版本控制，输出的结果也不稳定、难控制。他借用软件工程里成熟的做法——测试、CI/CD、包管理、安全扫描——来管理上下文，让团队能可靠地扩展 AI 编程代理，并对不确定的输出保持掌控，逐步积累组织知识。对读者的用处是：如果你想让 AI 编程助手在团队里稳定工作，可以借鉴这套把上下文当代码来维护的思路。目前材料只是演讲介绍，没有给出具体实施步骤或工具细节。
提供的材料未提及具体可用工具。
spring-ai-community/spring-ai-session · Structured, event-sourced conversation memory layer for Spring AI applications.
Spring AI Session 是一个 Spring AI 库，为 AI 应用提供结构化、事件溯源的会话管理能力。它把每条消息建模为带身份、时间戳、会话归属和可选分支标签的 SessionEvent，支持在历史过长时按轮次边界触发上下文压缩（compaction），并通过 SessionRepository SPI 在内存、JDBC（PostgreSQL、MySQL、MariaDB、H2）等后端之间切换。配合 SessionMemoryAdvisor 接入 ChatClient 后，调用会自动加载历史、追加消息并在需要时压缩，还包含事件过滤、多智能体分支隔离与跨会话召回等文档主题。
OpenAI 本月公开测试 Agents API，把支撑 Codex 的协调机制开放出来，能管理会话、调度工具和指挥子智能体。同一天，Cursor 推出 Projects，用来协调多个编程智能体完成更大的软件任务。两家做法不同，但都采用“协调者+专业智能体”的分工模式：协调者把握大目标、分派工作，专业智能体各自执行小任务。这样解决的是一个智能体上下文太长会变糊涂、变慢的问题，好处是可能让多智能体协作更可靠，但费用和协调风险也会增加。
dfrysinger/skills · My agent skills for GitHub Copilot CLI and other coding agents.
这是一个面向 GitHub Copilot CLI、Claude Code 和 Codex CLI 的可复用 Agent 技能库，覆盖需求调研（scout）、设计文档、原型、开发循环、独立双模型审查、视觉验证、无人值守长任务、会话交接与邮箱通信、技能创作与评测等环节，帮助编码 Agent 规划任务、保持长任务不跑偏、验证真实行为并保留上下文。仓库附带 session-control 与 mailbox-watcher 扩展，用于多会话通信与本地文件系统 IPC。
mochow13/keen-code · A context-aware terminal-based coding agent written in Go. Supports multiple-providers, MCPs, Subagents, Agent Skills, controllable tool output retention, hashline edits, and more.
Keen Code 是一个用 Go 编写的终端 AI 编程 Agent，面向常规软件工程任务，支持多家模型提供商、MCP、子代理、技能系统、哈希行编辑、上下文压缩与会话管理等能力，可通过脚本或 npm 安装并以命令行交互或 headless 模式运行。
文章作者做了一个实验：给 GitLab 公开文档做了一个聊天问答系统，拿一句包含五个不同问题的话去测试。主流做法是把复杂问题拆成五个小问题分别检索，再合并、重排、塞进有限的上下文窗口。结果五个正确答案虽然都被检索到了，但最终只有一条被保留，另外四条被排在前面的答案挤掉了；不拆分反而能保留三条。作者把这种现象叫“上下文饥饿”：某个子问题虽然找到了答案，却在最后分配上下文空间时被挤掉，而且常规召回率指标完全看不出来。文章指出，查询分解只解决了检索阶段的问题，分配阶段仍由“谁分高谁上”的不公平策略决定，需要引入公平性约束。目前这是作者在 GitLab 公开文档上做的实验，配套评测方法尚未说明是否开放使用。
数据库管理员（DBA）未来可能不再亲手管数据库，而是管一群替他们干活的 AI 代理。现在的问题是：AI 代理会带来大量零散、时忙时闲的数据库工作负载，没人手逐个开通和照看。Yugabyte 推出 YugabyteDB AMP（Agentic Multitenant PostgreSQL），把成百上千个小 Postgres 工作负载打包到共享分布式设施上、同时保持隔离，生命周期操作可通过 MCP 交给代理，另有 Meko 提供跨代理持久记忆。对读者来说，这意味着如果这套做法成立，小团队也能照看大得多的数据库资产，闲时代理不耗算力、按 CPU 分钟付费，且可从 serverless Postgres 平滑过渡到完整分布式 YugabyteDB。
LangSmith 新上线了一个叫 Trajectories 的功能，它能把一个 AI 智能体在一次长时间会话里做过的事，按发生顺序整理成一段像聊天记录一样的清晰视图，而不是一堆嵌套的复杂执行细节。以前调试这类智能体，得在层层嵌套的运行记录里翻找，很难快速看出它到底哪里做错了。现在可以先按顺序浏览整个会话，找到出问题的步骤，再点进去看完整细节，还能让非工程背景的专家直接用这个视图打分、挑毛病，并把有用的会话存成训练数据。对做智能体开发和运维的人来说，调试和人工审核都会更快、更省事。
LangChain 团队发布了 Managed Deep Agents 0.8，这是一个帮你构建、部署和运行生产级 AI Agent 的托管服务。过去团队想在生产环境跑 Agent，得自己搭建记忆存储、登录验证、消息入口和工具权限等基础设施，费时费力。这次更新直接内置了四样东西：按用户隔离的凭据和记忆（不同人用同一个 Agent，各自的信息不会串）、HTTP 通道（外部系统能通过 webhook 调用 Agent）、Slack 文件传输，以及基于 Parallel 的联网搜索工具。对开发者来说，这意味着少写大量重复代码，把精力放在 Agent 本身的行为设计上。目前已发布可用，但具体定价和开放范围原文未说明。
Cursor 团队说，他们优化了智能体（也就是能自己连续干活的 AI）跑长任务时的“上下文”组织方式：过去每轮请求都要重复带上大量系统提示和工具说明，费用高。现在他们精简了约 66% 的系统提示，把低频工具改成按需加载，并在 GPT-5.6 之后利用 OpenAI API 显式标记缓存断点，还改为每十行才标一次行号、更谨慎地使用子智能体。结果是整体 token 成本降低 7%，冷缓存未命中率降低 20%，缓存读取 token 减少 1.6%，智能体质量没有下降。这些经验也被用到了 Grok Bot 上。
ribeirorafadev/estrutura-pastas-superpowers · Scaffold de estrutura de pastas cross-agent (.agents/) + Spec-Driven Development (PRD/ADR/specs) + .editorconfig por linguagem, pra começar projetos novos com Claude Code, Cursor, Grok, Codex, Antigravity e outros agentes de IA. Skill do framework Superpowers.
该项目提供一个 Bash 脚手架脚本，用于新建项目时生成跨 Agent 的 .agents/ 单一事实来源目录、Spec-Driven Development 文档结构（PRD/ADR/specs/plans）以及按语言定制的 .editorconfig（每项缩进规则均标注官方来源）。支持为 Claude Code、Grok、Codex、Cursor、Kimi、Cline、Roo Code、Antigravity 等生成对应入口文件（CLAUDE.md/.claude/、AGENTS.md），也可通过 --here 就地生成，碰撞时不覆盖任何已有文件。同时以 Claude Code 原生 skill（Superpowers 框架）形式提供。