吴恩达最新项目：给 Coding Agent 补一层上下文基础设施

这篇文章，我是基于 andrewyng/context-hub 的 README、CLI 文档、内容规范文档，以及 2026-03-07 的最新提交整理出来的。先说清楚：我这次没有做完整安装实测，重点是把这个项目的设计思路讲透。

最近大家都在卷 Coding Agent。

Claude Code、Codex、Cursor、各种能写代码的 Agent，一个比一个聪明。但你真用下来，很快就会发现两个老问题一直没解决：

• 它会幻觉 API
• 它会忘记上一次踩过的坑

第一个问题大家都懂。明明你用的是新版 SDK，它却还在调用旧参数；明明官方文档已经改了，它还在按去年的示例写。

第二个问题更烦。Agent 这次好不容易试出来“某个接口要加特殊 header”“某个 webhook 校验不能先 parse JSON”，下次开新会话，它又忘了，然后重新踩一遍。

最近我看了 Andrew Ng 的一个新项目：Context Hub。

我自己的判断很直接：

这项目不是在做一个“更会搜文档”的工具，而是在给 Coding Agent 补一层长期缺失的上下文基础设施。

它到底是什么？

用仓库自己的话说，Context Hub 要解决的是：

• Coding agents 会 hallucinate APIs
• 会在会话结束后忘记学到的东西
• 需要 curated、versioned docs
• 还要能随着任务持续变聪明

它现在交付出来的东西，其实很朴素：

• 一个 CLI：chub
• 一套给 Agent 看的 Markdown 文档格式
• 一套本地注释机制
• 一套反馈给维护者的回路

安装也很简单：

npm install -g @aisuite/chub
chub search openai
chub get openai/chat --lang py

如果你只把它看成“命令行查文档”，那还是低估它了。

真正有意思的地方，不是查文档，而是“让上下文可治理”

我觉得这个项目最值得看的，不是 README 首页那几条命令，而是它背后的设计思路。

第一，它把“给 Agent 看的文档”单独抽了出来

我们平时看的官方文档，很多是写给人看的。

对人当然没问题，但对 Agent 不一定友好。Agent 真正需要的是：

• 当前版本到底是什么
• 语言变体是什么
• 最常用路径怎么写
• 哪些参考文件按需再取
• 哪些内容更值得信任

Context Hub 这里做得很干净。文档是 Markdown，前面带 YAML frontmatter，明确写：

• languages
• versions
• revision
• updated-on
• source

其中 source 还能标记信任级别：official、maintainer、community。

这个设计看起来很轻，但意义很大。因为这等于在说：Agent 不应该面对一坨混杂网页，而应该面对一份结构化、可判断来源、可识别版本的新型上下文。

第二，它支持增量获取，省 token，也更符合 Agent 的工作方式

很多文档系统的问题是，要么整本喂进去，要么自己手动切，两边都低效。

Context Hub 支持一种很实用的模式：

• 先 search
• 再 get
• 如果主文档后面还有附加参考文件，就按需 --file
• 真有必要，再 --full

比如：

chub get acme/widgets --file references/advanced.md

这件事看起来只是省 token，但本质不是。它其实是在逼文档作者把“主干信息”和“深水区信息”分层。对 Agent 来说，这比一篇巨长无比的官方文档友好多了。

第三，它最关键的设计，不是 feedback，而是 annotate

我觉得这个项目最聪明的地方，就是 annotate。

比如 Agent 在真实项目里发现：

• 某个 webhook 校验必须保留 raw body
• 某个版本有兼容性坑
• 你们团队内部只允许走 batch endpoint
• 某个错误要加指数退避

这些东西，官方文档里不一定有，但对“下次还能不能少踩坑”又极其重要。

你可以直接：

chub annotate stripe/api "Webhook verification requires raw body"

然后下次 chub get 这个条目时，这段注释会自动追加出来。

这个设计很像给 Agent 做了一个“针对具体文档的长期记忆层”。

不是大而泛的 memory，而是和具体 API 文档绑定的可持久经验。这一点我觉得特别对。因为 Agent 最缺的，往往不是常识，而是那些“只有做过一次才知道”的具体坑。

第四，它把“本地经验”和“公共反馈”拆开了

这里还有个细节，我觉得很专业。

Context Hub 明确把两件事分开：

• annotations：本地的，只给你自己的 Agent 用
• feedback：发给维护者的，用来改进公共文档

这很重要。因为并不是每条经验都适合公开。有的是你的环境特性，有的是你团队约定，有的是你们公司内部工作流。

如果把这些全部混成公共反馈，噪音会很大。

所以它把“今天先帮我别再踩坑”和“长期帮大家把文档修好”拆成两条链路。我觉得这个边界感是对的。

你可以把它理解成什么？

我自己的理解是：

Context Hub 更像是一个给 Coding Agent 用的“文档注册表 + 可持续记忆层”，而不是传统意义上的搜索工具。

如果一定要再说得更直白一点：

• 它不是 RAG 框架
• 不是向量数据库
• 也不是 MCP 的替代品

它更像是 MCP、CLI Agent、IDE Agent 这些系统上面缺的一块“高质量上下文供给层”。

Agent 负责调用工具、改代码、跑命令。Context Hub 负责尽量保证：它拿到的是更可信、更当前、更节省 token、还能越用越聪明的上下文。

这层如果做不好，模型再强，也很容易在“调用哪个参数”“当前版本怎么写”这种低级问题上翻车。

这个项目适合谁？

我觉得它最适合三类人：

1. 经常让 Agent 写 SDK/API 集成代码的人

如果你天天都在接 OpenAI、Stripe、Cloudflare、Anthropic、Datadog 这类服务，Agent 最容易翻车的地方就是文档和版本。

这类场景，Context Hub 很有价值。

2. 想给团队内部 Agent 提供私有规范的人

它支持本地内容目录和 chub build。也就是说，你完全可以把团队内部文档、最佳实践、历史坑，整理成一套自己的 agent-readable registry。

这个想象空间很大。

3. 做 Agent 基础设施的人

如果你在做自己的 Coding Agent、企业内部 AI 编程平台，或者自动化开发工作流，这项目特别值得看。

因为它给了一种很清晰的思路：

不要只优化模型和工具，也要优化“模型读到的上下文载体”。

我对它现在的判断

截至 2026-03-07，这个仓库是公开的，最近还在持续更新，最新提交就在更新 OpenAI 文档到最新模型和 SDK 版本。仓库当前大约 318 个 star，37 个 fork。

这说明它还很早期，但不是放出来就不管的 demo。

当然，它现在也不是“已经一统江湖”的成熟平台。从仓库现状看，我会给它一个比较克制的判断：

• 方向非常对
• 设计比很多“AI 文档工具”更工程化
• 真正的价值要看内容生态能不能持续长大
• 如果以后有更多官方维护者直接提供高质量条目，它的价值会明显上升

一句话总结就是：

Context Hub 最值得看的，不是它今天收录了多少文档，而是它试图定义“Agent 应该如何获取、保存、修正文档上下文”这件事。

这件事一旦做成，影响会比“又一个 AI CLI 工具”大得多。

制作不易，如果这篇文章觉得对你有用，可否点个关注。给我个三连击：点赞、转发和在看。若可以再给我加个🌟，谢谢你看我的文章，我们下篇再见！