一份 Launch HN 讲透了三层工程取舍 2026 年 8 月 31 日,Y Combinator S26 批次项目 Almanac 在 Hacker News 发了 Launch HN 帖,创始人 Kushagra 一上来就抛出一个很反直觉的观察:「给企业装一个 AI 智能体并不容易,我们花了几个月自己折腾 Hermes 才意识到这件事的难度。」 他的原话是:「设置 Hermes、让它说话对
一份 Launch HN 讲透了三层工程取舍
2026 年 8 月 31 日,Y Combinator S26 批次项目 Almanac 在 Hacker News 发了 Launch HN 帖,创始人 Kushagra 一上来就抛出一个很反直觉的观察:「给企业装一个 AI 智能体并不容易,我们花了几个月自己折腾 Hermes 才意识到这件事的难度。」 他的原话是:「设置 Hermes、让它说话对路、给每个连接器自己写 OAuth 应用、手动喂上下文、和 Hermes 的默认内存搏斗——这不是一个工程问题,这是一个产品空白。」
Almanac 的产品形态非常具体:用户注册后拿到一个开箱即用的 Hermes 智能体;支持 Gmail、Calendar、Granola、PostHog 等账号一键连接;区分个人账号(只有本人能看)和共享账号(全公司可见);底座是两层预编译 wiki——个人 wiki(理解你是谁、偏好、生活里的人、当前在做什么)和公司 wiki(公司是什么、当前在做什么、路线图、卡点)。Almanac 不只是一个 agent,更是 agent 背后的两层 wiki 知识库。
这条产品路径背后有一个非常具体的工程判断:多数 AI 助手把 memory 当 afterthought,Almanac 团队用了一年时间(为 Harvard 和 NASA 做产品)反复验证一件事——必须在前置编译(pre-compilation)上下重 compute 投入,才能让 agent 的回答「像它真的懂你」。 这是第一个公开把「memory 工程化」作为核心壁垒的 YC 项目。
「预编译 wiki」为什么是 2026 年的硬技术
帖子里 Almanac 团队提到一个关键能力:agent 不再是 session-bound(只跑一次、跑完即忘),而是 long-horizon(可以接住几天前的任务)。实现这个能力的关键不是更大的 context window,而是把「ongoing projects」作为 wiki 的常驻章节维护——Almanac 替你发出一封邮件,4 小时后对方回信,agent 看到回信、基于 wiki 上下文自动起草 follow-up。这种能力跟过去 12 个月所有「让模型记住」的工作都不一样——它不是把对话历史塞进 context,而是预先把工作流的关键状态(项目目标、决策历史、依赖关系)编译成结构化 wiki,让 agent 在任何时刻都能查到。
第二个关键能力是后台 worker + 主动推送。Almanac 跑一个 background worker,定期扫一下「目前哪些任务可能可以自动完成」,然后 ping 主 agent,主 agent 再 ping 用户,建议「我可以帮你自动化这件事,要不要试一下」。Kushagra 给的例子里,他早上醒来会看到一条「我已经给你准备好了融资 pitch deck 草稿,要不要看一下?」——这就是「预编译 wiki + 后台 worker + 主动建议」三件套直接产出的效果。
第三个能力是真实的跨用户场景。帖子里列了几个上线用户:有人用 Almanac 跑狗救助运营(找寄养家庭、跟踪接送、发提醒签同意书);有人研究 Polymarket 策略(wiki 记住过去策略,提出新策略,对比上次对错);有人建营销 campaign(不用每次重新解释业务和整个 campaign)。这些场景都不是「AI 写代码」或「AI 答客服问题」这种典型任务,而是「AI 跑一个长期、多步骤、需要持续记住上下文的真实业务」——这是 2026 年下半年 agent 产品形态开始真正分化的标志。
Context Plugin:另一条解决「agent 不懂你的 API」的路径
几乎同期(2026 年 9 月 3 日,8 天前),API 集成平台 APImatic 发了另一个相关项目 Context Registry for AI coding agents。他们解决的问题跟 Almanac 不同,但工程哲学非常相似:让 agent 在不爆 context window 的前提下拿到生产级的 API 集成上下文。
APImatic 团队的痛点观察很具体:大多数 coding agent 写基础 API 调用还行,但在「生产级集成」的细节上一致性地摔跟头——idempotent retries、rate-limiting、Auth token 管理这些细节,agent 经常漏掉或写错。他们试过当时所有上下文注入方案:MCP 投递的 markdown 文档(比如 Context7、Mintlify Docs MCP)、用 AGENTS.md + skills 写散文描述 API 行为、OpenAPI spec——全都留下了同样的「生产就绪度」缺口。
他们的解法是 Context Plugin:把散文描述 + 类型化 SDK reference code 打包成一个插件,agent 工作到涉及某个 API 时自动注入语言特定的上下文。实验数据显示 Context Plugin 把 one-shot production readiness 提升了最多 34%,让 Sonnet 在同样的集成任务上可以追平甚至超过 Opus 的基线。这意味着对很多实际企业集成场景,「用更好的上下文注入」比「换更强的模型」ROI 高得多——这是给所有 2026 年下半年做 agent 产品的人一个非常直接的工程信号。
两条路径合起来看:agent 的企业大脑正在分层
把 Almanac(企业知识 wiki 预编译)和 APImatic(API 集成 Context Plugin)放在一起看,可以发现 2026 年下半年 agent 的「企业大脑」正在变成一个分层堆叠结构。
最底层是连接器层——OAuth 接入 Gmail/Calendar/PostHog 等企业账号。Almanac 把这件事做成「一键连接」,背后是连接器供应商统一管理 OAuth 凭据(Almanac 自己不存凭据,只存 wiki 和引用源)。这一层是商业护城河:谁掌握了更稳定的连接器生态,谁的企业 wiki 就有更完整的输入。
第二层是预编译 wiki 层——Almanac 的核心壁垒。把分散在 Slack/Gmail/PostHog 的原始数据,经过大规模 LLM 处理(团队原话是「compute upfront」),编译成结构化的「个人 wiki」和「公司 wiki」。这一层的成本结构是:前期 LLM 处理投入大,后续每次 agent 调用边际成本接近零。对个人用户可能 50-200 美元一次性处理,企业级 5,000-50,000 美元;但一次投入后,agent 后续调用成本只取决于 wiki 体积和检索开销。
第三层是上下文注入层——APImatic Context Plugin 走的是这条路。它的输入不是用户的工作数据,而是第三方 API 的生产级用法。这一层的成本结构是「插件作者一次性写好,无数 agent 重复消费」,跟 wiki 层的成本模型不同。两条路径可以叠加:用 Almanac 跑公司内部 wiki,接 APImatic Context Plugin 跑外部 API 集成,agent 同时获得「公司大脑」和「外部世界手册」。
第四层是 long-horizon 任务编排——Almanac 的 background worker + long-horizon task 模型。任务不只是「用户问 → agent 答」的单跳,而是「agent 主动观察 → 决定行动 → 跨小时/天执行 → 在合适时机 ping 用户」。这一层对 agent 框架提出了根本性要求:不是「会话框架」而是「项目框架」。
「数据 + 记忆 = 知识」的口号背后,是企业 AI 落地最难的一道坎
Setoku(2026 年 7 月)曾给出一个非常精炼的产品口号:「data + memory = knowledge」。这句话道出了 2026 年企业 AI 落地的核心难题——数据有,但没有结构;agent 能调用,但没有长期记忆;理论上能推理,但实际上跑几次就忘了上下文。
Almanac + APImatic 两条路径同时给出的答案都指向同一件事:企业 AI 落地最大的瓶颈不是模型能力,是上下文工程的工程化。模型层面 2026 年下半年已经基本到顶(前沿闭源旗舰 + 开源中档够用),但 agent 在企业里跑不通,90% 的失败不是因为模型不行,而是因为没有把企业的「人 / 流程 / 数据 / 决策历史」编译成 agent 可以稳定检索和推理的结构。
这条路对 2026 年下半年的企业 IT 决策有三个非常具体的启示。
第一,采购 AI 助手时,问「memory 工程是怎么做的」,不要问「用的是什么模型」。 Almanac 的整个壁垒就在 memory 工程化上——同样的 Claude/GPT,接在 Almanac wiki 上和接在裸 LLM API 上,产出质量差一个数量级。采购 RFP 里要明确要求厂商提供「memory schema」「retention 策略」「wiki 更新频率」「proactive trigger 机制」这四项技术细节,不要只看 demo。
第二,长期任务的 agent 化要按项目而非会话设计。 传统 chat/会话框架(session-based)对 long-horizon 任务是灾难——用户问一次,agent 答一次,下次再说,过去全忘。Almanac 的 long-horizon + project framework 模型才是 2026 年下半年企业 AI 落地的正确形态。这意味着采购的 agent 平台要支持「项目状态」「跨会话记忆」「后台 worker」「主动推送」这四项基本能力,缺一项就别买。
第三,Context Plugin / context registry 这类「中间层」会是未来 12 个月的创业热点。 APImatic 的 34% production-readiness 提升是非常硬核的数据——意味着 context quality 比 model tier 更影响实际产出。企业里未来 6-12 个月最值得做的项目不是「更好的 LLM」,而是「更好的 context 中间件」——API 集成 / 内部系统上下文 / 数据语义层 / 决策历史 wiki,每一条都是空白赛道。
一个还没人解决的开放问题
这两份发布合在一起,暴露了 2026 年下半年企业 AI 落地领域最大的一个开放问题:context 的归属与交换标准。Almanac 的 wiki 是封闭的(用户数据 → Almanac wiki),APImatic 的 Context Plugin 是开放的(第三方作者写,无数 agent 消费)——但目前没有跨厂商、跨平台、跨工具的 context 互操作协议。你的 Almanac wiki 不能导出成标准格式让另一个 agent 平台消费;APImatic 的 Context Plugin 不能读 Almanac wiki;企业内部 IT 把 wiki 数据迁到新平台要重做一次。
这个问题跟前面提到的 agent delegation 标准(Authorizer 2.4 + Bitroad)、agent 工具发现标准(Armature + TDQS)、agent 长记忆标准(Decispher + Awareness Local)是同构的——2026 年下半年,agent 生态的成熟度主要看「标准化工作能不能跟上产品创新速度」。任何一个产品走得快、标准没跟上,最后都变成一座孤岛;反之,谁能率先拿出一个开源、被广泛接受的 context schema,谁就在下一个 agent 时代的生态层占据主动。
对企业来说,这意味着今天选 agent 平台时,「数据是否能完整导出」「wiki 是否开放标准」「context 能否被其他 agent 消费」 要进入采购清单——不是 nice-to-have,是避免被锁死的核心要求。
