当一个 Agent 对贷款、合同、医疗资料或内部审批给出结论后，最难回答的往往不是“结果是什么”，而是“当时依据了哪些资料、规则和历史判断”。普通对话记录能保留文本，却很难稳定表达来源、版本、实体关系和后续影响。semantica-agi/semantica 将这些系统外部的事实、决定和证据组织为可查询的关系结构，目标是为需要问责的 AI 工作流补上一层上下文基础设施。
它不是模型思维链的还原器，也不会自动判断业务结论是否正确。它保存的是进入系统的材料、显式规则、输出决定、关联对象和操作轨迹。因此，它适合放在需要追溯、复盘和权限治理的工作流旁边，而不是替代领域负责人对事实与风险作出的判断。
一、决策可追溯性从一个具体问题开始
设想一个自动审批流程拒绝了一份申请。三个月后，客户、审计人员或业务负责人需要追问：引用的是哪一版政策，哪些字段触发了规则，是否出现过相似案例，后来资料是否发生变化。若所有信息散落在提示词、日志、向量索引和不同数据库里，排查会退化为人工拼接。
可追溯的系统应把“结论”看成一个带上下文的对象。它至少关联输入资料、提取出的实体、适用规则、时间、版本、责任边界和后续操作。这样，复盘不只是重新读一段聊天文本，而是能够沿着证据链回到具体材料和当时状态。
二、关系图把材料、规则与决定连接起来
Semantica 的核心表达是图结构：人物、公司、任务、文件、规则和决定可以成为节点，引用、影响、冲突、更新和执行等关系成为边。Agent 在选择云服务、批准采购或生成合同时，可以记录任务场景、候选方案、最终判断、可靠性和依据来源；后续产生新决定时，再把它与旧决定建立显式关联。
图不是为了让数据看起来更复杂，而是为了支持反向提问。例如，某条政策变更影响过哪些决定，某份文件支撑过哪些结论，某个实体的不同名字是否被错误地当成两个对象。这些查询在单纯的会话存档中通常需要临时拼接，在关系模型中则是原生问题。
三、来源、时间和版本要一起保存
一条结论如果只留下最终文字，几乎无法判断其可靠性。更有用的记录应指向具体 PDF、表格、网页片段、数据库字段或导入批次，并标明写入时间和材料版本。资料被替换、修订或撤回后，系统仍应能区分“当时看到的版本”和“当前有效的版本”。
这也要求接入方保留稳定标识符与版本策略。没有明确来源的节点不应被包装成已验证事实；无法确认的抽取结果应保留置信度和待核验状态。溯源能力的价值不在于堆积更多日志，而在于让每个关键断言能够被定位、质疑和更正。
四、导入是建立上下文的第一道质量门
文档、表格、网页和数据库记录进入系统后，可以被解析为对象与关系。重复对象需要合并，矛盾材料需要显式标记，而不是让较新的内容静默覆盖旧内容。否则，关系图会把输入噪声固化为看似完整的知识网络，反而提高错误结论的说服力。
实践中应先确定资料许可、敏感级别、保留期限和来源字段，再选择抽取规则或模型。对实体名称、单位、日期和业务主键设置验证样本；对冲突记录规定升级路径。自动抽取负责减少整理成本，事实确认仍由数据所有者和业务规则承担。
五、可视化 Explorer 适合检查局部关系和演变
关系图的浏览界面适合做两类工作：从一个对象出发查看邻近关系，以及沿时间维度检查资料、规则和决定如何变化。决策页应能展示输入与后果，来源页应能回到原始材料；当两个对象疑似重复时，工作人员需要能够审阅并决定是否合并。
可视化不能替代数据质量检查。节点越多，越应提供过滤、局部视图、时间范围和关系类型约束，避免把一张巨大网络误当成解释。面向审计和业务复盘的页面还应显示来源、版本和访问权限，而不是只突出连线数量或布局效果。
六、多 Agent 共用上下文时要区分共享与授权
研究 Agent 找到的材料可以交给分析 Agent 继续使用，后续任务也可以查询已有决定，减少重复收集和彼此矛盾的个人记忆。但共享上下文不等于所有角色都拥有相同权限。读取资料、写入候选事实、确认实体、修改规则和删除记录应是不同级别的动作。
一个稳妥的分层是：采集角色只写入待审核材料，分析角色引用已批准记录，负责人确认高影响决定，审计角色只读访问完整轨迹。将角色、数据域和操作类型写入权限模型，才能避免“长期记忆”演变为未经审查的共享污染源。
七、MCP 接入应建立在清晰的工具契约上
通过 MCP，支持该协议的工具可以将记录决定、检索历史、查询原因和读取关系图变成可调用动作。真正需要先定义的是契约：调用方应提供哪些来源、对象标识和权限上下文，返回结果如何区分已验证证据与推测，失败时是否会产生半完成写入。
对外部写入必须提供幂等键、预览、审计日志和停止能力。对于高影响决定，系统可先生成证据摘要和拟写入关系，待负责人确认后再提交。工具调用的方便性不能成为跳过来源核验、权限检查和回滚设计的理由。
八、部署重点是数据边界、备份和访问控制
图数据、来源文件和决策记录往往比普通对话更接近业务核心。部署前需要明确数据存储位置、网络范围、加密、备份、恢复演练和保留策略。测试环境应使用脱敏样本；生产环境应对服务账号、管理界面和数据库连接设置最小权限，并记录管理操作。
Explorer 一类界面不应以匿名模式直接暴露在公网。API 密钥、反向代理、身份认证、网络隔离和速率限制应作为基础配置，而不是事后补丁。任何能够读取关系、来源或历史决定的接口，都应按数据敏感级别进行授权和审计。
九、快速迭代项目必须纳入补丁与风险管理
上下文基础设施常同时处理图查询、文件导入、管理界面和 API，因此升级策略应包含安全公告跟踪、版本锁定、测试副本验证和可回退方案。已部署实例不能只因“功能正常”就停止维护；认证缺失、查询注入和公开端口等问题会直接扩大对敏感关系数据的暴露面。
上线前应完成最小威胁建模：谁能读取来源，谁能写入决定，谁能修改规则，攻击者如何利用查询或导入接口，备份是否会泄露历史数据。把升级、密钥轮换和异常告警纳入运行手册，才能使可追溯性本身成为可信能力。
十、从高价值且可审查的流程开始试用
适合首批试点的场景包括法规或合同审阅、内部审批、研究结论归档、事故复盘和跨 Agent 的证据交接。先选择一个资料来源稳定、影响可控、可人工复核的流程，记录导入质量、查询命中率、追溯时间、人工修订量和恢复演练结果，再决定是否扩大范围。
对于只需保存少量个人偏好的助手，简单记忆工具通常成本更低。Semantica 的优势会在决定需要影响业务、需要保留证据、需要理解关系和需要接受审计时体现出来。可靠的采用标准不是图谱规模，而是系统是否能清楚回答：这项决定依据什么、谁可以修改、资料后来如何变化，以及出现问题后如何恢复。
十一、把追溯查询写成可重复的验收用例
落地时可以为每类高影响决定准备固定验收问题：给定一项决定，能否在限定权限内找到输入资料、规则版本、关联实体、时间戳和后续修改；删除或撤回一份来源后，系统是否保留历史状态并明确标记当前结论不可用；恢复备份后，关系、来源和审计日志是否仍然可以互相对应。将这些问题变成自动化测试和人工抽查，才能避免图谱只在演示环境里完整。
同样重要的是反向测试：伪造重复实体、矛盾日期、缺少来源的结论和权限不足的查询，确认系统会拒绝、降级或提示人工确认。对于涉及外部写入的流程，再验证幂等键、回滚记录和重复恢复不会产生第二次副作用。追溯能力只有在异常样本上也成立，才值得进入正式业务。