我们做 RAG、接知识图谱、上智能体，最后常常卡在同一个尴尬：它能算、能答、能演示，却记不住自己刚做过什么。这篇讲一个真实跑通的动态本体 MVP——DeepSeek Harness 怎么把"决策"从一次性输出，变成写回本体空间的结构化记忆。
很多人以为智能体的分水岭在于"能不能调用工具"。其实不是。调用工具只是最基础的一步，真正的分水岭在更后面：它能不能把每一次决策写回本体，让系统"记住"自己为什么这么做。
一、DeepSeek Harness：一句话让整个系统动起来
先交代这个 MVP 的完整技术栈，它不是单个 Agent，而是一条端到端链路：
- DeepSeek Harness：接收自然语言任务的入口。用户不用点一堆按钮，只要在对话框里下达任务。
- MCP：把智能体和本体运行时连起来的桥。Agent 通过 MCP 选择本体、创建任务、准备工作区、运行函数，最后刷新前端。
- 本体运行时：承载两个已经跑通的本体。
- Cesium 数字地球：把东海防空识别区（ADIZ）、空中目标、历史航迹、预测航迹、预警机阵位、跑道形值班航线全部可视化出来。
两个本体，各有各的活：
- air target threat assessment——空中目标威胁研判，输出 ADIZ 进入概率预测；
- awacs position_planning——根据敌方进入概率，规划我方 KJ-2000 预警机阵位。
链路是清楚的：用户下达任务 → Agent 经 MCP 选本体 → 跑函数 → 刷前端。这条链路解决了「智能体如何调用本体」和「本体如何驱动应用」，但它还缺一样东西——记忆。
二、会算，但不会记：V0.03 的断点
V0.03 能算也能展示。比如你问"基于当前敌机进入东海防空识别区概率，规划我方预警机阵位"，本体会输出一个 PositionPlan，前端把推荐阵位、候选阵位、起飞机场、值班航线全显示出来。
但追问下去就露馅了：
- 这次为什么选这个阵位？用了哪些目标的概率？哪些情报支撑？
- 是否触发人工复核？
- 如果人工复核后认为方案不合适，这个反馈如何影响下一次规划？
这些不是日志能解决的。日志记录"发生过什么"，却不会自然形成业务对象之间可追问的关系。三个具体问题随之而来：
- 解释链路变短——能答"当前推荐什么"，答不好"上次为什么这么推荐"；
- 复核反馈无法沉淀——人工说"阵位太靠前、生存性风险偏高"，写在报告里就没了，下次智能体不会知道；
- 本体衔接不闭环——第一个本体输出概率，第二个本体消费概率，中间缺一个稳定的"决策记忆层"来记录每次跨本体调用的上下文。
三、V0.033 的核心：把决策写回本体空间
受 Semantica 项目（Context Graph + Decision 一等对象）启发，V0.033 做了一次关键升级——不是推倒重来，而是吸收两个思想：
第一个思想：Context Graph。 普通智能体记忆是文本式的（"用户说过什么""任务做到哪"），对业务决策不够用。这里需要的是结构化记忆：某次研判用了哪些目标、哪些情报、哪个函数版本、哪个本体、哪个规则、哪个动作门控，最后有没有被人工复核。
第二个思想：Decision 作为一等对象。 过去容易把决策当成函数返回值——一段 JSON、一张卡片。正确姿势是：既然 AirTarget、IntelReport、AirspaceZone 是对象，那么 PositionPlan、ThreatAssessment、AdizEntryProbability 也应该是对象，而且能被追踪、连接、复盘、反馈。
两个思想合并成一句话：
函数输出不是终点 → 形成 Decision Object → 写回 Context Graph → 成为动态本体的结构化记忆层。
具体做了四类改造：
① 本体模型新增 Decision Object 类型。 建模工具里除了数据源、对象、Link、Function、Action、应用层，多了 Decision Object 和 Context Graph。DecisionRecord、DecisionOutcome、DecisionFeedback、ContextGraphMemory 都成了画布上的明确元素——业务专家建模时能显式声明：某函数输出不只展示结果，还要写回为决策记录；某复核结果不是普通备注，而是后续推理可用的反馈对象。
② 本体运行时增加决策写回结构。 预警机阵位规划函数 rank_awacs_position_plan 不只返回推荐阵位，还返回 decision writeback，记录 decisionId、decisionType、inputObjects、functionChain、selectedResult、alternatives、actionGate、humanReviewState、writeback target。这样一个 PositionPlan 不再是孤立结果，而是和上游 AdizEntryProbability、候选阵位、人工复核任务、动作门控连成一体。
③ MCP 运行时新增 Context Graph 查询能力。 新增 query_context_graph。以后 DeepSeek Harness 遇到"查询上次阵位规划的决策依据""为什么选 ORBIT-CENTRAL-BACKSTOP""上次复核通过没""有哪些反馈要避免"，不是去翻聊天记录，而是调本体工具查 Context Graph，返回结构化结果。
④ 前端新增 Context Graph 可视化工具栏。 主控台顶部加一个 Context Graph 按钮，打开的不是本体建模图，而是运行时记忆图——展示当前任务里关键研判、规划输出、复核状态、写回记录之间的关系。
四、"回写"到底改变了什么
"回写"容易被理解成"把结果写进数据库"。这里的决策回写，是把函数输出重新变成本体空间里的对象和关系。
对比一下前后的差别：
V0.03：rank_awacs_position_plan → 推荐 ORBIT-CENTRAL-BACKSTOP（一次性答案）
V0.033：rank_awacs_position_plan → PositionPlan → DecisionRecord
→ HumanReviewTask → ContextGraphMemory（结构化业务状态）
四个实打实的好处：
- 可追问：问"为什么推荐这个阵位"，沿图谱找依据——DecisionRecord → selectedResult → PositionPlan → used AdizEntryProbability → consumed EnemyAirTarget / AirspaceZone / SupportAsset → functionChain。
- 可复盘：复核通过写 DecisionOutcome，驳回写 DecisionFeedback（"阵位靠近威胁走廊前沿，生存性风险偏高""保障资源不足，不满足持续值班条件"）。
- 可学习：下次任务先查 Context Graph 找历史相似决策的反馈。这不是大模型参数更新，而是业务层的结构化经验更新——更可控、更易审计。
- 可协同：空情研判本体输出 AdizEntryProbability，预警机规划本体消费它输出 PositionPlan；未来再加"拦截方案规划本体""雷达资源调度本体"，直接消费上游 Decision Object，而不是翻原始表。
一句话：Context Graph 记录的是业务结构，不是程序流水。
五、升级后的五层动态本体模型
V0.033 之后，整个系统的分层变得清晰：
- 数据层：态势数据、航侦/技侦报文、开源地理、历史案例库、我方平台状态、雷达模型库、保障资源库。
- 语义层：对象和 Link——AirTarget、TrackPoint、IntelReport、AirspaceZone、OwnAwacsPlatform、CandidateOrbit、SupportAsset，以及 HAS_TRACK_POINT、SUPPORTED_BY_REPORT、LOCATED_IN_OR_NEAR、SUPPORTS_MISSION_PACKAGE 等关系。
- 动能层：Function、Action、Skill——
predict_adiz_entry_probability、assess_threat、rank_awacs_position_plan是函数；update_cesium_overlay、update_awacs_orbit_overlay是动作；adiz-entry-probability、awacs-position-planning 是可被 DeepSeek Harness 渐进式加载的 Skill。 - 动态层：不再是"输出层"，而是 Decision Object 层——ThreatAssessment、AdizEntryProbability、PositionPlan、HumanReviewTask、DecisionRecord、DecisionOutcome、DecisionFeedback 都在这，记录当前任务的业务状态、决策结果和复核反馈。
- 应用层：Cesium 数字地球、DeepSeek Harness Console、报告审计视图、Context Graph 可视化工具栏——消费本体输出，但不替代本体做业务判断。
最关键的跃迁是：动态层开始承担"记忆"的责任。
六、对智能体成长的意义：三条成长线
整个系统的成长分三条线，V0.033 补强的是第三条：
- DeepSeek Harness 的记忆系统——负责对话层、任务层、用户交互习惯的记忆；
- Skill 的成长——好的计算方法、踩过的坑、参数修正、复核政策，沉淀到 SKILL.md、scripts/、references/。比如阵位规划 Skill 逐步补充更好的巡逻航线模型、生存性评估模型、保障资源约束；
- 动态本体本身的成长——对象、Link、Function 会变多，Action policy 会调整，Decision Object 和 Context Graph 会记录越来越多业务经验。
这一步补强很关键：它让本体不只是"执行当前任务的语义层"，也成为"记录历史决策的业务记忆层"。
一个只会调用函数的 Agent，顶多是工具编排器；一个能在本体空间里读写决策对象、查询上下文图谱、吸收复核反馈的 Agent，才开始接近真正的业务智能体。
反过来，这也让风险边界更清楚——每个 DecisionRecord 可以记录 allowed_effect、review_state、audit_required，高风险输出只能进人工复核，不能直接自动执行。
七、这套实践，印证了企业本体该往哪走
回头看，这个 MVP 的进化路径，恰好回答了企业本体建设的一个核心问题：本体除了"理解与行动"，还要不要"记忆与成长"？
答案是肯定的。用一个更普适的框架串起来（这也是尚云在做 OAG 时强调的同一条链路）：
- RAG 让智能体找到信息；
- 本体（OAG）让智能体理解并守规行动；
- 决策写回 + Context Graph 让智能体记住并成长。
三者层层递进。企业 AI 的分水岭，不是模型能不能写出一段流畅的回答，而是它能不能理解企业、在企业规则内推进工作，并且——记住自己为什么这么做。
下一步要解决的是"写回之后怎么用得更深"：让 DecisionRecord 真正持久化、让 Harness 在任务开始时主动查 Context Graph、让 DecisionFeedback 反向沉淀进 Skill。做完这些，动态本体才从"会算"走到"会记"，再往后才谈得上"会成长"。
一句话收尾：智能体的分水岭，从来不是会不会调用工具，而是会不会把每一次决策写回本体——会算只是入场券，会记、会复盘、会成长，才是业务智能体真正的门槛。
