周一早上开新会话，我照例给 coding agent 贴一段说明：订单服务的错误码怎么分段，哪几张表不允许在业务代码里直接更新，跑集成测试要带哪个 profile。这段话存在我本地一个文本文件里，一周要贴好几次。哪次贴漏一条，它就按通用习惯写出一段在我们组过不了评审的代码。很长时间里我把这当成提示词写得不够好，从没往别处想。
我做后端七八年，以往去云栖基本只听数据库内核和存储相关的场次，今年第一次专门坐进讲数据库与 Agent 的技术主论坛。去之前我预期的是新品发布加几张架构图，回来时笔记本上记得最多的，是一个和那个文本文件直接相关的判断。
台上那句"有限的 Token 预算"
主论坛那天，杨辛军在演讲里发布了两个新品，一个解决 Agent 运行时的数据放在哪里、怎样低成本运行，另一个是 Agent Context。后者的讲法比我想的朴素。台上先描述了一个大家都遇到过的情况：同样一个要求，经常需要重新解释；放到企业里更麻烦，不同用户有不同习惯，同一个词在不同业务里含义也不一样。接着举了一个例子，一个 Agent 处理过一次业务异常，下一次遇到类似情况，它应当能找到上次的处理过程，判断条件是否相同，用户不必把背景从头再讲一遍。
收益那一句我原样抄了下来：在有限的 Token 预算下，把更相关的信息交给模型。
演讲的结构我也记了一笔。前半段讲数据底座，后半段的过渡语是：有了底座之后，企业的各种多模数据怎样转化为 Agent 能用的上下文，帮它理解业务、记住已经发生的事。台上把这称作第二层升级。我理解这个顺序的用意，数据库团队来做上下文，出发点是"数据放在哪、怎么变成可用的输入"，跟做 Agent 框架的人从提示词和编排出发，视角不太一样。对后端开发者来说，前一种视角反倒更容易接上。
主论坛之后的新闻稿把 Agent 的短板概括成三个词：记不住、接不上、复用不了。我对照了一下自己的情况。记不住，是新开会话就忘了 profile；接不上，是我上周让它排查到一半的问题，这周换个会话得重讲一遍现象；复用不了，是同组同事用 Agent 修过同一类错误码，我的 Agent 对此一无所知。三条都中。
回头再看，我平时对 Agent 的理解可以分成三个变量。模型决定能力上限，工具决定能执行哪些动作，上下文决定它此刻依据哪些事实、规则和经验去做动作。三者互相替代不了。推理再强的模型拿到过期规则，会稳定地给出过期答案；工具列表再长，缺了当前任务状态和权限边界，Agent 只会更快地调用错接口。我那份文本文件，就是我在手工供给第三个变量，供给得很粗糙：每次全量贴，从不更新版本，也没有任何权限概念。
被说服的部分：供给是一条链路
散会后我在笔记里补了一段自己的理解。很多团队手上已经有文档库、数据库和历史会话，却仍然供不上合适的上下文，问题通常卡在四个位置。
最先碰到的是数据散落。事实在数据库和数仓里，流程规则写在钉钉、飞书这些协作平台上，执行经验留在对话或任务反馈里，图片和音视频又各有各的解析方式。
更新速度也对不上。存量导入做完之后，新增、修改、删除和权限变化同样要进入链路。我们组的接口规范一年改好几次，我那份文本文件至少落后两个版本。
剩下两处都出在检索回来的东西上。整篇设计文档适合人读，Agent 执行某一步时需要的可能只是一个业务对象、几条约束和一个对应方法，粒度不对。内容看着相关，却答不上来源、作者、时间、权限和版本，缺治理信息。
主论坛没有把这四点逐条展开，我回来翻分论坛公开的材料，才在连接器那一页看到细节：数据源和 Agent 之间放一层连接器，结构化数据走授权访问，钉钉文档、飞书文档这类内容通过同步任务导入，分一次性同步和增量同步，增量同步监听文件变化持续更新，同步时保留来源、作者、时间、权限和版本。
把这些放在一起，我心里就有了一张后端更熟悉的图：持续同步、语义组织、检索组合、治理控制，四段串成一条数据链路，提示词只是链路末端的输出格式。做过 CDC 或缓存失效的人应该能体会，费劲的从来不在"把数据读出来"，在变化怎么传播、旧数据怎么失效、谁能看见什么。
三类资产，正好对上我那份文本文件
Agent Context 把上下文分成 Memory、Knowledge、Skill 三类。按官方的定义，Memory 来自 Agent 的对话和任务执行，属于 Agent 和用户私有，带概率性，未必稳定；Knowledge 可以共享也可以私有，一部分由记忆里的高价值内容提炼而来，一部分是企业验证过的原始文档直接入库；Skill 是 Agent 在执行中结合前两者形成的任务方法，会随执行持续更新。
我拿自己那份文本文件对着过了一遍，里面其实混着三种东西。"集成测试带哪个 profile"是我个人的工作习惯，换个同事可能用别的 profile，更像 Memory。"哪几张表不能直接更新"是团队规则，应该有出处、有版本，还应该只对有权限的人可见，属于 Knowledge。"遇到某一段错误码时先查哪张流水表、再看哪个下游回调"是一套可重复的排查方法，接近 Skill。
混在一起贴，当下省事，代价是私有习惯被当成了团队规则，排查步骤也脱离了它的适用条件。这个划分逼着我说清楚每条内容该怎么用、能给谁用。三类资产之间可以流转，但有条件：一次任务里选了哪个方案，先进 Memory；提炼、审核之后，稳定的部分变成团队共享的 Knowledge；一套能重复执行的方法沉淀成 Skill 候选版本。少了审核、版本和授权，攒下来的多半是噪声。
检索之后还有一次组装
这一段我在主论坛只听到个轮廓，细节是对照分论坛材料补的。Context Engine 组合了向量检索、全文检索和图关联查询，把差异屏蔽掉，对 Agent 只暴露一个 search 入口。知识单元由两部分组成：按 chunk 组织的图谱内容，以及存放在 OSS 里的原始文档。Agent 可以先沿实体找到关联实体，需要核对时再下钻原文，用的是渐进式披露的加载方式。
我更愿意把这层理解成一条组装流水线。检索找候选，权限过滤划掉不能用的，版本和来源帮助判断可信度，任务意图决定最终拼成什么样。后台任务同时在维护这条流水线，处理记忆冲突，替换已经固化但不再适用的知识。单纯追求召回率解决不了这件事，无关内容塞进上下文同样消耗 Token，还会分散模型的注意力。我那份文本文件的问题恰好在这里：每次全量贴，相关的、不相关的、过期的一起进去。
三组数字，我怎么记
主论坛给了三组数字：万级 Agent 工作空间数据共享，Token 使用效率提升 3 倍，复杂知识任务准确率提升 50 个百分点，依据客户真实场景估算。
我在笔记里把这几个数字和"估算"两个字圈在了一起。它们说明厂商在优化哪三件事：共享范围、预算利用率、复杂任务质量。至于放到我这种几个人的后端组上能有多少收益，场景不同，任务分布不同，只能拿自己的任务集测。我不打算转述这些数字当作自己的预期，下文也不会出现我自己的任何"提升多少"，因为我还没测。
第一组数字说的是规模上限，对我们这种五六个人、每人一两个 Agent 的小组没有直接意义，我关心的反倒是下限：工作空间里只有很少的文档和记忆时，召回会不会因为候选太少而硬凑一些弱相关的内容进来。后两组数字说的是效率和质量，它们和任务的类型强相关，知识密集、跨文档的任务和单文件的小改动，结果不会一样。
还没被说服的地方
主论坛的时长决定了它只能讲方向，所以我带回来的疑问比结论多。下面只记和后端工作关系最大的几个。
先说 Memory 的"概率性"。官方自己说记忆带概率性、未必稳定，这个坦白我认同。麻烦在于，Agent 根据一条错误记忆做了动作，我从结果上很难反推是哪条记忆出的问题。数据库里一行脏数据，我能查到写入时间和写入方；一条被提炼出来的"事实"错了，我能不能同样追到它是哪一轮对话、什么上下文里提出来的，主论坛没有讲到。后来翻帮助文档，看到有整理、去重、冲突处理和遗忘管理，但这些解决的是记忆之间的关系，对单条记忆的来路能追到多细，我还要自己验证。
增量同步里的删除，我更不放心。新增和修改容易做，删除和权限收窄最容易漏，我做数据同步时在这上面吃过亏。材料里写了 Agent Context 的连接器会处理新增、修改、删除和权限变化，可删除之后旧的 chunk、图谱里的实体关系、已经被提炼进记忆的内容是不是都跟着失效，我在会场上没有办法确认，回来也还没测到这一步。
还有组装的可见性。Context Engine 把向量、全文、图三路检索屏蔽在 search 背后，对 Agent 是简化，对排查问题的人却多了一层黑盒。某次 Agent 拿到了不该拿的内容，或者漏了该拿的内容，我需要知道是召回没找到、排序靠后，还是被权限过滤掉了。帮助文档里有 ctxdb debug 相关的命令，我还没来得及用。
这些疑问不动摇"数据链路"那个判断。只是链路上每一段都得能观测、能回溯，不然出了问题我只能凭感觉调。
回来后的一次小尝试
周末我按帮助文档用 CLI 脚本装好，接到了自己用的 Agent 上，过程本身不复杂。
装完先确认连通：
ctxdb status ctxdb ping
然后在控制台建了一个知识库，把那份文本文件整理成一篇规范文档，连同订单服务的两份设计文档一起传上去：
ctxdb kb upload-file svc-docs ./docs/order-service-conventions.md --wait ctxdb kb search "哪些表不允许在业务代码里直接更新" --kb=svc-docs --top-k=6 --verbose
搜索带上 --verbose 之后，每条 chunk 会多出 doc_name、kb_id、doc_id，我能直接看出它是从哪份文档里取的，这对我判断"它答对了是不是碰巧"很有用。
这次尝试我只看了召回到的内容是不是我预期的文档，没有做任何量化对比。CLI 安装时会同时配置 Hooks，之后记忆的召回和写入都自动进行。我这次有意只看知识库检索这一路，记忆那部分留到正式跑任务集时再观察，免得两个变量搅在一起，事后分不清是谁起的作用。
哪些场景不需要这一整套
回来跟组里同事聊，有人问：我们那个只回答部署 FAQ 的小机器人要不要也接？我的看法是不用。如果 Agent 只回答一组更新很少的公开问题，没有用户私有状态，不调用业务工具，也不承担审计要求，定期重建的静态检索库已经够了。硬上记忆晋升、图关系和生命周期管理，维护成本很可能高过收益。
我给自己定了四个判断问题：任务是否跨轮次延续，信息是否频繁变化，执行是否受权限约束，出错后是否需要追溯来源。命中越多，上下文越应该当成独立的基础设施来对待；命中很少，就继续保持简单。我们的订单服务开发四条都占，部署 FAQ 一条都不占。
接下来的测试计划
我打算从过去一个月自己和 Agent 的会话记录里挑三十个左右的任务，按三类整理：需要跨会话接着做的，需要同时参考两份以上文档的，涉及表权限或变更约束的。每个任务记三件事：我是否还需要手工补背景，Agent 实际读进去的上下文里有多少和任务无关，产出能不能一次过评审。先在不接入的状态下跑一轮做基线，再接入后跑一轮，两轮用同一个模型、同一套任务描述。
这几项大致对着主论坛那三组数字的方向：共享和接续、预算利用、复杂任务质量。"无关"怎么判定，我准备自己逐条标注，标准写在任务集的说明里，免得第二轮跑的时候不自觉放宽。Token 消耗就用 Agent 客户端自己的统计，不另外造工具。
任务集里我会故意放几个"反例"任务，比如只需要读一个文件就能完成的小改动。接入之后如果这类任务的上下文反而变长、变杂，说明召回阈值或者注入策略需要调，这比看平均值更能暴露问题。测出来是什么样，我现在不知道，也可能在我们这种规模上差别不明显，那同样是一个有用的结论。
时间上，我给这件事留两周。第一周只整理任务集和基线，不碰接入配置；第二周接入后跑同一批任务，跑完把每个任务实际召回了哪些文档记下来，和我标注的"应该用到的文档"对一遍。
还有一个问题，我打算在接第二个数据源之前就问清楚。模型可以整体替换，上下文供给却嵌在数据、权限和流程里。一旦 Memory 的晋升记录、Knowledge 的版本链、Skill 的评估历史都沉淀在一个外部服务中，这些东西以什么格式导出，治理规则能不能跟着迁走，我在帮助文档里还没找到明确说明。
