为 AI 分析 Agent 构建上下文：少即是多

在为大模型驱动的分析 Agent 设计上下文时，「该把哪些事实放在哪里」往往比「上下文够不够」更棘手。某团队在过去半年里多次重建其分析 Agent 的上下文层：起初采用结构化实体图、面向机器的定义，以及一个用于校验查询计划能否被模型落地的把关层；最终，他们砍掉了其中绝大部分，只保留了最关键的一条——当 Agent 无法把答案锚定到已知事实时，直接拒绝回答，而不是猜测。

从实体图到导航树

支撑他们最终方案的核心原则只有一句话：「一个事实，一处权威定义」。同一个事实可以在生成视图中出现，也可以在其他位置被引用，但只能在一个地方被编辑——这是控制维护成本的关键。

在此之上，他们构建了一棵从根出发的导航树，每个元素都拥有从根节点开始的路径地址，文档之间通过地址互相链接，因此整棵树实质上是一个有向图。一个客户活动域下的文档可以直接指向收入域的某个指标，而非只能挂在自己的父节点上。

具体到分层归属，同义词挂在列上，表的粒度写在表上，指标的公式写在指标上，跨多张表的业务规则放在对应的领域文档中，真正全局生效的规则才放到根上下文里。对于无法纳入结构化字段的业务语境，则使用 Markdown 描述来承载。

让 Agent 走同一张图

查询时，Agent 只拿到根域的简要地图与一个用于探索上下文的工具。它先请求某条路径，返回该节点的上下文、子节点、表摘要与指标，再按需拉取详细的 schema 与 join 信息。这是一种「模型主导路由」——Agent 沿着确定性图谱前进，而非在搜索结果中筛选相关片段。

这种放置策略直接影响效果：表放错域就难被发现，不分配则等于隐形；所有东西都堆在根节点，则会出现典型的「上下文腐烂」，无关材料越多，模型对真正相关事实的推理反而越差。团队内部测试显示，约束 Agent 只探索相关分支，比给它完整搜索工具，上下文 token 用量减少约 45%。

沿图遍历还带来一个搜索无法提供的保证：要抵达深层节点，Agent 必须先经过通向它的父级或链接路径，因此拉取到的任何事实都已经带有路径上下文的语境，指标永远不会脱离定义它的域被孤立读取。

歧义与「无聊」的细节

面对「上个月法国有多少活跃客户」这类问题时，根规则会先识别出「活跃」一词存在歧义，主动询问用户采用哪种定义（例如「过去 30 天有付款发票」），再依次检索相关定义文档、检查表与 join，并基于存储值 FR 生成 SQL，最终连同引用过的路径与上下文版本一起返回。

歧义并非假设。在一次测试数据集中，两种合理的「活跃」定义返回的数量相差接近 4 倍。在一个 5 题的内部测试中，加入「主动暴露未定义限定词」的根指令后，Agent 平均请求澄清 4 次；去掉该指令则降为 2 次。

与此同时，看似琐碎的细节同样关键：FR 这种国家代码映射应当写进上下文，join 的基数信息应当挂在 join 上。不过文章也强调，这些都不取代仓库级的访问控制——Agent 能检索的上下文、能执行的查询，仍需遵守表权限、行级策略与敏感数据限制。

维护路径要显而易见

最后，作者指出，没有人愿意再维护一个需要每周五下午手工更新的目录。当一列发生变化时，机器应当能够自动定位受影响的事实并沿着图谱传播更新。上下文的价值，最终取决于它能否被持续维护下去，而不是上线时有多漂亮。