一次任务里，Agent可以把项目约束、资料和修改过程都放进上下文。到了下一次会话，同样的背景又需要解释：哪份政策有效，哪个决定已经确认，上次留下的问题究竟解决没有。执行速度提高后，这些交接成本反而更显眼。
Google于11月12日介绍 Gemini 4 Hydrogen，强调日常编码、调试、交互式开发与Agent工作，支持四档thinking，也可以与Carbon、Argon协作。快速完成下一步，并没有自动回答另一个问题：下一项任务从哪里取得团队当前认可的知识？
先分清模型、宿主和知识层
模型处理本次送入的上下文。承载模型的Agent或应用负责会话、工具调用及如何取回资料。外部知识层保存可跨任务读取的文档、结构化事实和方法。
接入Busabase的是具备工具能力和权限的宿主或应用。使用Gemini API构建应用时，需要应用自己协调读取、组织上下文和写回；选择某个模型不会自动给所有Google界面加上同一个连接器。先确认实际宿主可选用Hydrogen，再确认该宿主的MCP或REST能力。
记忆、知识库与正式记录的区别可以帮助划界：临时推理放会话，长期说明放文档，其他任务要依赖的事实保留来源、责任人和状态。
结构示意 · 可调整的工作方法
给资料、事实和方法各自一个位置
以下是可调整的起步设计，并非预置Hydrogen集成。一个Folder组织相关资源；Doc保存项目目标、规则和适用范围；Base保存需要查询的事实；Skill保存读取、去重、提案和验收的方法。
事实Base可用短标题作为主字段，再加主题稳定键、当前结论、来源URL、适用范围、负责人和业务状态。任务结果可保存在另一张Base中，以relation关联用过的事实，并记录产物URL、未解决问题和验收结果。不要为了整理而复制已经有维护者的完整资料，优先链接原始来源。
第一轮只做读取和上下文准备
按Bring Your Own Agent或MCP接入指南连接实际宿主。核身份与Space，先做只读检查；多个Space时明确选择，不把默认值当作用户选择。
然后让Agent搜索本工作区的playbook，读取相关方法和项目Doc，再按当前任务查找适用事实。交给模型的上下文应包含结论、来源、范围及待确认点。不要把整个工作区一股脑塞进提示词，也不要让过期记录仅因匹配到关键词就变成执行依据。
结构示意 · 可调整的工作方法
把新发现写成可判断的提案
可以这样给连接后的Agent下指令：
读取这个项目的约束和当前有效事实，为本次任务整理来源明确的上下文。完成工作后，把可复用的新结论与现有主题记录比较；已有主题提出字段修改，新主题再提新增。保留实际来源、产物和未解决问题。需要人审的变更只提案，返回差异与链接。
输出应包括约束清单、真实产物和知识变更提案。工作结果与可长期复用的事实分开验收：代码产物有自己的测试，业务结论由相应负责人确认。不要把Agent的一句“完成了”写成所有结果已被接受。
让下一次任务读取当前认可的版本
Busabase写入通过ChangeRequest留下差异和历史。proposal-only权限让提案等待审核；write权限可能即时合并。若要求共享知识先经人审，应在权限或支持的请求参数中落实。
合并后读回当前记录，核关键字段和来源关系。下一次会话重新读取当前版本，并按业务状态和适用范围筛选；merged只说明字段变化已进入canonical，不自动等于业务结论已确认。来源变更、范围冲突或资料失效时，返回负责人判断。
结构示意 · 可调整的工作方法
什么情况下值得增加这一层
单次问题、资料少且没有后续依赖时，一个会话和原始文档往往足够。任务反复发生、多个Agent共享资料、业务事实持续变化，或需要知道谁确认过什么时，共享知识层才更有价值。
从一个项目、一份约束Doc和一组真实事实开始。完成读取、执行、提案、审定、回读，再用新会话继续同一问题。可检查的结果是后续任务找到当前有效资料及其依据，而不是宣称模型权重记住了公司知识。先从连接自己的Agent建立这个小循环。