本喵手记 · AI Agent 科普

AI Agent 驾驭工程全解

内核只有一段调 API 的代码，其余全是「可随时装卸」的外设

深度科普 + 实战经验 · 2026-09 · 面向工程师 / 架构师 / 产品经理

喵开场白：为什么本喵要写这篇长文

先立个flag：这不是一篇营销软文，也不是入门教程，而是给“已经跑过 Agent、准备认真对待它的人”的一份驾驭工程地图。

（小声）先自我介绍：这篇是本喵写的。本喵平时见到生人就躲，闻到奶油味才回来，但这次得站出来：有朋友把一整晚花在"装积木"上，第二天早上 Agent 还是不会干活。本喵看着实在着急，尾巴都翘不起来了。

所以把那点怯劲儿收一收：咳咳，本喵可是认真的哦。这篇长文会把整个 AI Agent 摊开给你看：哪里是内核、哪里是外设、哪些钱本来不该花。哪里讲不清楚，欢迎回来骂本喵（……不可以骂太久）。

本喵在 Hermes 中文社区混迹已久，见过太多朋友掉进同一个坑：看到 MCP 火了就搭 MCP，看到 记忆体 火了就上记忆体，看到 Skill 火了就囤 Skill，结果一整个晚上都在“搭积木”，第二天早上发现 Agent 还是不会干活。

问题出在哪？出在大家把“额外功能”当成了“必备组件”，把驾驭工程（steering / orchestration engineering）当成了 Agent 本身。

所以本喵决定写一篇能把事情讲透的文章：

先立主心骨：AI Agent 最核心的东西只有一点，用一段代码（Python 等）去调用大模型 API。模型本身、MCP、记忆体、工具、Skill、Agent 框架、各种编排层……全部是“非必要，但非常有需要的额外功能”，它们存在的唯一目的是：确保输出 OK、更好地完成工作。
再回答两个灵魂拷问：这些组件到底是“分布式排列”还是“牵一发动全身”？布置完 DSH / Hermes 之后，周边模块是“一次性布置清楚”还是“支持模块化更新、按需装卸”？本喵会用 DSH（DeepSeek Harness）和 Hermes 的真实机制来回答，不空谈。
最后查漏补缺：分专业、分赛道，把整个驾驭工程的全貌摆给你看，Prompt、上下文、记忆、工具、MCP、Skill、多智能体、模型网关、运行时、可观测性、部署、安全、Workflow 边界……一个都不少。

口吻是本喵的，严谨是全文的：每一个关键论断都标注了来源，文末有可点击的参考文献清单。欢迎拿去推敲、拿去打脸。

🐱 读者画像：你已经跑过一个（或好几个）Agent，甚至自己部署过 DSH / Hermes，正在思考“我的工程化水平到底够不够”。如果刚入门，建议先跑通“一段代码调 API”再看这篇，体验完全不同。

1核心论点：一切皆外设，唯有调用是内核

用一句话原理图，先把整个世界观立起来。

图 1-1 · 核心-外设原理图：Agent 的“内核”极小，“外设”极多，且外设必须可替换

为什么敢这么下结论？因为整个 Agent 的“智能”并不存在于框架里。把系统提示词、工具列表、历史消息塞进一次 chat.completions 请求，模型返回文本或函数调用，这 一个回合（turn） 就完成了 90% 的“智能”动作。剩下的回合循环、重试、记录，你手写 200 行 while 循环也能做到，只是会很难看、很难维护而已。

所以本喵给全篇文章立三条基准：

内核（必要）：模型 API + 你的调用代码。没有它，一切皆无。
外设（增强）：工具、MCP、记忆体、Skill、上下文工程、多智能体……它们让 Agent“做得成事、记得住事、靠得住”，但没有一个是你“必须”为最小可用版本买单的。
点缀（锦上添花）：缓存、观测看板、路由降级、花式编排……它们让系统“跑得快、看得清、撑得久”，缺了照样能跑。

后面每一章都会沿着这条光谱展开。别忘了：判断一个组件该不该上，先问它“离内核多远、能不能随时拆掉”。

1.3 最小内核：20 行代码就是全部

说一百遍「内核极小」，不如直接看。下面这段没有框架、没有编排器，只有官方 SDK 和一次 while 循环，它已经是一个能跑、能自己读文件的 Agent 了：

minimal_agent.py

import json
from openai import OpenAI

client = OpenAI(base_url="https://api.deepseek.com")   # 密钥走环境变量，别写进代码

TOOLS = [{"type": "function", "function": {          # ① 工具 schema：赛道 ④
    "name": "read_file",
    "description": "读取一个文件的前 4000 字",
    "parameters": {"type": "object",
                   "properties": {"path": {"type": "string"}},
                   "required": ["path"]}}}]

def run_tool(name, args):                            # ② 工具分发：本机代码负责执行
    if name == "read_file":
        return open(args["path"], encoding="utf-8").read()[:4000]

messages = [{"role": "system", "content": "需要看文件就调用 read_file。"},
            {"role": "user", "content": "帮我看看 README.md 讲了什么"}]

for step in range(10):                               # ③ agent loop：赛道 ⑨ 的雏形
    r = client.chat.completions.create(model="deepseek-chat",
                                       messages=messages, tools=TOOLS)
    msg = r.choices[0].message
    messages.append(msg)
    if not msg.tool_calls:                           # 模型不再要工具 = 收工
        print(msg.content)
        break
    for tc in msg.tool_calls:                        # 要工具，就执行完再喂回去
        out = run_tool(tc.function.name, json.loads(tc.function.arguments))
        messages.append({"role": "tool", "tool_call_id": tc.id, "content": out})

图 1-2 · 最小内核：一次请求 + 一个循环 + 一张工具表。后面每一个赛道，都是在这段代码外面长出来的东西

三个标号就是三条赛道：工具 schema 怎么写（赛道 ④）、工具谁来执行（赛道 ④ + ⑫ 的安全边界）、 循环什么时候停、崩了怎么续（赛道 ⑨ 运行时）。所以「驾驭工程」不是另一个东西，它是这三行标号的放大版： schema 越写越清楚、工具越加越多、循环越来越不容易崩。仅此而已。

图 1-3 · 内核就是这块会发光的方块：外面的零件怎么堆都行，但它一灭，堆得再花也白搭

2概念逐个拆解：每个组件是什么、解决什么、离内核多远

下面每个概念都给四个要素：“是什么 / 解决什么 / 与核心的距离 / 主流玩法”。距离判定用三档徽章：必要贴近内核增强锦上添花

概念 2.1 · 模型与 API（真·内核）

是什么：大语言模型（LLM）本身，以及你通过 HTTP 调它的那扇门，OpenAI / Anthropic / DeepSeek / 各类兼容端点。对代码而言，它就是一个 POST /v1/chat/completions。

解决什么：解决“从文本到文本的智能映射”。模型的“能力”是训练出来的，不是工程搭出来的，工程只能放大、约束、组合它。

与核心的距离：必要它就是核心本身。注意：模型不等于 Agent，Agent 是“包着模型的那层电路”。

主流玩法：2026 年的现状是，多模型混用成为默认（贵的模型做规划，便宜的做干活/蒸馏）；OpenAI 兼容协议成为事实标准，几乎所有本地推理服务（vLLM / Ollama / llama.cpp）都提供兼容端点；DSH 甚至把“自定义 OpenAI-compatible endpoint”做成了一等公民配置项（provider ID + base URL + protocol + key），换模型不换代码。

来源：DSH 官方仓库 docs/（自定义 provider 与 profile/bundle/patch 组装均为一等公民，见 github.com/deepseek-ai/deepseek-harness）；Hermes 官方文档 hermes-agent.nousresearch.com/docs（“Switch with hermes model— no code changes, no lock-in”）。

概念 2.2 · 调用层 / Agent Loop（内核的第二行代码）

是什么：那个“发请求 → 看返回 → 如果是工具调用就执行工具 → 把结果塞回去 → 再发请求”的循环。也叫 agentic loop / 推理-行动循环。

解决什么：把“一次对话”变成“一次能自己调用工具、自己纠正、自己继续的任务执行”。它解决的是一次调用解决不了的问题。

与核心的距离：贴近内核你甚至可以自己写：while not done: resp = client.chat.completions.create(...)。框架的价值只在“循环的可维护性”，不在“智能”。

主流玩法：一个相当极端的做法来自 DSH，Agent Loop 本身也被做成了插件。Cordis 的注册表里 ctx.agentLoop 和模型适配器、工具注册表平级，替换循环驱动只是一个配置行，而不是 fork 源码（来源：akillness.github.io 对 DSH 架构文档的拆解；DSH 官方仓库 docs/architecture.md 原话：“including … the agent loop itself … There is no privileged core to patch”）。Hermes 侧则提供 execute_code：让模型写一段 Python，把“多步工具调用流水线”压成一次推理调用的零上下文开销回合（来源：hermes-agent GitHub README）。

来源：Fodev JEO《DeepSeek Harness: What If the Agent Loop Itself Were Just Another Plugin?》(akillness.github.io, 2026-08-15)；NousResearch/hermes-agent README。

概念 2.3 · 工具与函数调用（tool / function calling）

是什么：在请求里附带 tools=[{name, description, parameters(JSON Schema)}]，模型若认为需要，会返回 tool_calls，你的代码执行后把结果作为新消息回填。

解决什么：让模型“动手”，查数据库、读文件、跑命令、发消息。它是 Agent 从“聊天机器人”升级为“办事员”的临界点。

与核心的距离：增强但它实现起来只是“多两个字段 + 一段分发代码”，是离内核最近、性价比最高的增强。

主流玩法：JSON Schema 描述参数已成通例；支持并行工具调用、强制工具调用（tool_choice）；工程重点转向“工具描述怎么写才不被模型误解”“工具越多幻觉越高，如何收敛”；再往上就是 MCP 这类协议化抽象（见 2.4）。

来源：OpenAI Function Calling 文档（platform.openai.com/docs/guides/function-calling）；Anthropic Tool Use 文档（docs.anthropic.com）。

概念 2.4 · MCP（Model Context Protocol）

是什么：Anthropic 2024 年底开源的“模型上下文协议”，一个让 Agent 客户端和外部能力服务器（filesystem、github、slack……）统一握手、发现、调用的插电板标准。

解决什么：解决“N 个 Agent × M 个工具 = N×M 个适配器”的爆炸问题。协议化之后，任何支持 MCP 的客户端都能接任何 MCP server，就像 USB-C 一样。

与核心的距离：增强它没有改变“调 API”这个动作，只是改变了“工具列表从哪里来”。甚至可以说：MCP 是“工具工程”的协议化包装，属于标准的“非必要但有价值”。

主流玩法：2026 年的现状，spec 稳定推进（stdio / SSE / Streamable HTTP 三种 transport），官方 registry 出现，Hermes / DSH / Claude / 各家 IDE 全面支持接入 MCP server；工程重点从“会不会接”转向“server 怎么配、权限怎么限、配置怎么管理”。

来源：modelcontextprotocol.io（官方 spec）；Hermes 官方文档 MCP Integration 章节。

概念 2.5 · 记忆体（memory）

是什么：让 Agent 跨会话、跨上下文记住东西的一切机制，从最朴素的 MEMORY.md 追加写入，到向量库 RAG、到 Mem0 / MemGPT 这类“记忆即产品”，再到本喵主理人自研的 Mnemosyne-OS 这类“记忆宫殿”。

解决什么：解决“对话一结束就失忆”“上下文一满就断片”。本质是把“上下文窗口”延伸成“人生阅历”。

与核心的距离：增强注意一个反直觉事实：记忆体做得再花哨，检索到的东西最后还是要拼回 prompt 里，还是同一次 API 调用。所以“记忆工程”是典型的“外设”而非“内核”。

主流玩法：分层记忆（工作记忆 / 长期记忆 / 档案）；混合检索（向量 + BM25 + RRF 融合）取代纯向量；重排（rerank）提升精度；记忆生命周期管理（写入 → 蒸馏 → 衰减 → 遗忘 → 复现）成为 2026 年的新焦点，Mnemosyne-OS 正是这条赛道的完整实现，§6 会详细拆。

来源：Mnemosyne-OS README（github.com/gymaira1990-jpg/Mnemosyne-OS）；Mem0 官网 mem0.ai；MemGPT/Letta（letta.com）。

概念 2.6 · Skill（技能）

是什么：把“完成某类任务的方法”（提示词 + 步骤 + 可选代码 + 元数据）打包成一个可被发现、可被装载、可被模型自主调用的单元。有人叫它“过程性记忆（procedural memory）”。

解决什么：解决“同样的活每次都要现教一遍”。Skill 让 Agent 把“做过一次的事”沉淀成“下次直接会做的事”。

与核心的距离：增强它的本质是一段更好的 prompt + 更规矩的流程，最终依然汇入同一次 API 调用。胜在可移植、可共享、可版本化。

主流玩法：开放标准 agentskills.io（Hermes 已兼容，可跨平台移植共享）；Hermes 还能在复杂任务完成后自主创建技能、并在使用中自我改进（来源：hermes-agent README “Autonomous skill creation after complex tasks. Skills self-improve during use”）；DSH 侧有 skills 插件位；社区在争论“Skill 到底是 prompt 包还是代码包”，答案是两者都算，按需。

来源：agentskills.io；NousResearch/hermes-agent README；Anthropic Agent Skills（anthropic.com/engineering/agent-skills）。

概念 2.7 · Agent 框架（framework）

是什么：LangChain / LlamaIndex / LangGraph / CrewAI / AutoGen / 以及“框架即产品”的 DSH / Hermes 这类运行时。它们把循环、记忆、工具、状态管理做成现成零件。

解决什么：解决“从 200 行 while 循环到生产级系统”之间的工程债：状态管理、重试、日志、并行、升级兼容。

与核心的距离：增强框架是“外设的收纳盒”，它管的是外设，管不了智能。选框架的判据：它允许你多大程度地替换/卸载它的零件（DSH 在这点上做到了极端）。

主流玩法：两大阵营分化，轻量派（直接用 SDK + 自己 200 行循环）与重量派（LangGraph 这类图式状态机）。DSH 的答案是“框架 = 插件内核 + 配置组装”，Hermes 的答案是“一个自改进的完整产品”。中间地带正在被“harness（驾驭台）”这个概念填上：框架管外设，harness 管“外设的装卸与组合”。

来源：github.com/langchain-ai/langgraph；github.com/microsoft/autogen；github.com/deepseek-ai/deepseek-harness；github.com/NousResearch/hermes-agent。

概念 2.8 · 编排层（orchestration / multi-agent）

是什么：让多个 Agent（或一个 Agent 的多次任务）协作的层：orchestrator-worker 模式、subagent 委托并行、流水线编排、以及 MoA / MoE 这类“多个模型投票/分诊”的思路。

解决什么：解决“一个循环搞不定的大任务”。把任务拆成可并行、可分工、可复核的单元。

与核心的距离：锦上添花它是最外面的一层，把若干个“内核”串起来。顺序反了会灾难：内核没跑通就上编排，等于在沙地上盖十层楼。Hermes 的实现是把 subagent 做成隔离的并行工作流（spawn isolated subagents），DSH 则能把 Claude Code / Codex 整个作为子代理插件挂进自己的树里（dsh-subagent-claude-code / dsh-subagent-codex），连“别人家的 Agent”都只是一个配置行。

来源：hermes-agent README；AgentConn《Inside DeepSeek Harness: A Kernel, Not a Rival》(agentconn.com, 2026-08-23)。

💡 读到这里先记住一张表：内核 = 模型 + 调用代码（必要）；紧贴内核 = Prompt / 循环 / 工具分发（贴近内核）；外设 = MCP / 记忆 / Skill / 框架（增强）；最外层 = 编排 / 网关 / 观测 / 安全（锦上添花）。下面两章，就是围绕这张表回答两个核心问题。

图 2-1 · 概念距离光谱：越靠左越接近“非做不可”，越靠右越要“随时可拆”，注意编排层与 Skill 在最右，别本末倒置

2.9 术语速查：看到这些词，先问它离内核多远

后面各章会反复出现这些词。本喵给你一张对照卡：左边是词，中间是它到底管什么，右边是它离「一段代码调 API」的距离，距离越远，就越该"随时能拆掉"。

词	它管什么	离内核的距离
turn（回合）	一次「发请求 → 收回复」；一次 Agent 任务通常由很多个 turn 组成	内核动作本身
Agent Loop	把很多个 turn 串起来、中间插入工具执行的那个循环	贴近内核
tool call（工具调用）	模型说「我要执行 read_file」，由你的代码去执行再把结果喂回去	贴近内核
上下文窗口	这一次请求最多能装多少 token；装不下就要压缩或丢弃	贴近内核（物理限制）
上下文工程	决定每一轮往窗口里塞什么、丢什么（含压缩、笔记、子代理隔离）	增强
上下文腐烂	窗口越长、噪声越多，模型的有效召回越差	现象（不是组件）
RAG / 向量检索	把外部知识按相似度捞回几段，拼进 prompt	增强
rerank（重排）	粗略捞回 20 条后，用小模型精排出最相关的 3 条	锦上添花
MCP	把「工具」标准化成可插拔的 server，让 N×M 个适配器变成 N+M	增强
Skill（技能）	把「某类事怎么做」写成可发现、可装载的文档包	增强
Harness（驾驭台）	把模型、工具、循环、记忆装在一起并管好装卸的那层产品	外设的收纳盒
缓存命中 / 缓存读	同样的前缀第二次发出去时按更低的价计费；命中率取决于前缀稳不稳	治理层（省钱）

表 2-1 · 术语速查卡：整篇文章只需要记住一句话，越靠下、越靠右，就越该"能拆"

3核心问题一：组件是“分布式排列”还是“牵一发动全身”？

社区里吵得最凶的问题。本喵的答案是：都不是，是“分层耦合”。内核与参数微耦合，外设彼此弱耦合，接口处强耦合。下面给出可判断、可操作的标准。

3.1 先把耦合画清楚：四层架构模型

图 3-1 · 四层架构模型：每层的“耦合性格”完全不同，别把不同层的耦合混为一谈

3.2 耦合矩阵：哪些“牵一发动全身”，哪些“各自为政”

组件 A ＼组件 B	模型	Prompt	工具 schema	MCP server	记忆体	Skill	循环	编排层
模型	—	弱-中换模型常要调 Prompt，不重写代码	弱-中工具描述要适配模型风格	弱协议互通即可	弱 Mnemosyne 换 env 即换模型	弱标准可移植	弱 DSH ctx.llm 槽	弱子代理各自带模型
Prompt	同左	—	弱-中工具调用格式写进指令	弱	弱注入格式约定	中 Skill 本质是 prompt 包	中循环指令嵌入	弱
工具 schema	同左	同左	—	中 MCP 把工具变成协议资源	弱	弱	强分发器与 schema 一一对应	弱
MCP server	同左	同左	同左	—	弱 server 之间互不感知	弱	弱	弱
记忆体	同左	同左	同左	同左	—	弱	中靠注入 hook 挂进循环	弱
循环	同左	同左	同左	同左	同左	同左	—	中编排要约定循环的进出契约

图 3-2 · 耦合矩阵（本喵的工程判断，非文献标准）：红色=强耦合，橙=中/弱-中，绿=弱。强耦合点极少，且都集中在“同一个进程里直接调用”的地方

判断标准：问你四个问题

替换成本：换掉它，是改一行配置（hermes model、改 .env、加一个 --patch），还是要改调用代码，还是得推倒重来？→ 对应“弱 / 中 / 强耦合”。
影响半径：它变了之后，谁必须跟着动？只有它自己 → 弱耦合；它 + 一个适配器 → 中；全链路都要回归 → 强耦合。
耦合点收敛在哪：双方唯一握手的地方是不是一个显式契约（协议 / JSON Schema / 事件名 / 文件格式）？是 → 耦合可控；不是（靠隐式约定、靠顺序）→ 迟早出事。
能否单独测：把这个组件从系统里拎出来，配假数据能不能跑通自己的测试？能 → 松耦合；不能 → 它可能根本不是组件，是系统的一部分。

✅ 正例：DSH 的 ctx.llm 服务槽，消费方只声明“我要一个 llm”，从不 import 具体实现，所以换模型适配器是换配置行（来源：EggStriker 对 DSH 架构文档的拆解：“a consumer only knows there is a ctx.llm, never whether it is DeepSeek or OpenAI behind it”）。Mnemosyne-OS 同理：任何 OpenAI 兼容端点都能换，EMBED_MODEL / LLM_MODEL_LITE / LLM_MODEL_PRO 环境变量一换，零代码改动（来源：Mnemosyne-OS README）。

⚠️ 反例（真实存在的“牵一发动全身”）：Prompt 与模型能力、工具 schema 与分发器、上下文格式与记忆体输出，这些地方改了“A”，必须同步验“B”。它们才是你该小心维护的“契约面”。

3.3 影响半径图：换一个组件，天会塌到哪一层？

图 3-3 · 影响半径图：先给组件排“换它要付出多大代价”，再决定要不要为它建适配层

本喵的结论（可拿去跟架构师对线）

“分布式排列”和“牵一发动全身”同时为真，只是发生在不同层：同层之间默认分布式、可独立装卸；跨层之间必须通过显式契约，契约一旦变化就是“牵一发动全身”。所以真正的工程动作不是“追求完全不耦合”（不可能，也不该），而是：

把 强耦合点收敛到少数几个显式契约（API 格式、工具 schema、事件名、记忆注入格式）；
给每个外设配一个 适配器/服务槽（DSH 的 ctx.* 槽、Hermes 的 provider 抽象），让“换实现”永远只动配置行；
给高影响半径的变更（Prompt、框架升级）留 回归基线，这就是为什么评估与可观测性（§5 赛道 9）是正经工程的一部分。

4核心问题二：布置完 DSH / Hermes，周边是“一次性”还是“模块化增删”？

答案：模块型，支持模块化更新与按需加载/卸载。这不是本喵拍脑袋，是 DSH 和 Hermes 写在架构里的真实机制。下面用真机制说话。

4.1 DSH：一切皆插件，连“Agent 循环”都是插件

DeepSeek Harness（dsh）2026-08-13 开源，MIT 协议，基于插件内核 Cordis（DeepSeek 将其源码级 vendored 进 monorepo，改名 @deepseek-ai/cordis）。官方仓库 docs/architecture.md 原话：“Every part of the product is a plugin, including the model adapter, the tool registry, the session log, and the agent loop itself. There is no privileged core to patch.”，没有任何特权内核需要你改源码。

关键机制（来源：DSH 仓库 docs/architecture.md、docs/cordis-primer.md；社区拆解见文末参考）：

Profile / Bundle / Patch 组装路径：Profile 是命名组合（列出它叠哪些 bundle、放你自己的 patch）；Bundle 是分发格式（Cordis 配置 + 挂载代码）；Patch 是补丁清单（按 id 替换整行配置或插入新行）。
默认 dsh-base bundle 就是一份插件清单（社区拆解在 0.1.1-rc.2 上数出 78 条插件行；本机 0.1.7-rc.2 实测 93 条 / 528 行 YAML），“DeepSeek 眼中的最小可用 Agent”长什么样，以及“每一行你都能删掉”（来源：AgentConn 拆解）。
分层组合，没有 main()：bundle 按 profile 顺序 → profile 的 patch → home 级 patch → 命令行 --patch 覆盖，逐层叠出一棵插件树。可以用 dsh --profile web --dump-config 打印机器实际会启动的配置树，打印出来的每一行都能被你的 patch 替换。
运行模式也是配置：官方随发行版交付的 profile 有 web / headless / sdk / sdk-minimal / acp 五个，选哪个只是 --profile 的一个参数；社区另记录了 Standard / PTC / Minimal / Creation 四个 preset（能力组合包），两者都是“按 id 打 patch”拼出来的，不是另一份代码。

图 4-1 · DSH 的 Profile / Bundle / Patch 分层组装：加模块 = 叠一层 patch；删模块 = 去掉一行

4.2 Dynamic Cordis：运行中的动态装卸（进程内热插拔）

“模块化更新”到什么程度？DSH/Cordis 支持进程内动态路径：运行中登记、激活、停止、清理动态 Package（社区拆解文章所称的 cordis_define / cordis_run / cordis_stop / cordis_undefine 四个操作，覆盖“登记 → 激活 → 停止 → 回收”全生命周期），配合 Cordis 的 热重载（hot reload），加一个工具、换一个适配器不需要重启整个 harness。

为什么能做到“卸载干净”？因为 Cordis 的两条核心性质（有论文背书：《A Programming Paradigm for Spatiotemporal Composability》，北京大学与 DeepSeek-AI Harness 团队合作 preprint，2026-08-13 草稿，约 88 页）：

可逆效果（Revertible Effects）：每次注册（工具 schema、事件监听、适配器……）都带一个运行时拥有的“逆”，卸载时按注册逆序回滚，像一摞盘子从顶往下拿，不会留半注册的残留。对应代码里的 ctx.effect() 与 disposer。
反应式余效应（Reactive Coeffects）：组件声明自己“需要什么依赖”，依赖没齐就安静地待在 PENDING，齐了才被激活（activate），装个新插件，它自己会等该等的服务。生命周期状态机：PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED。

图 4-2 · Dynamic Cordis 进程内动态装卸：热插拔不是口号，是可逆效果 + 状态机的工程结果

来源：DSH 官方仓库 docs/architecture.md、docs/cordis-primer.md；Fodev JEO 拆解（akillness.github.io）；EggStriker.AI 两篇深挖（eggstriker.com/en/blog/deepseek-harness-cordis-architecture-2026）；AgentConn 拆解（agentconn.com）。cordis_define/run/stop/undefine 四操作名见 DSH 社区拆解文章（社区说法）。

4.3 Hermes：插件三发现源 + 两套扩展机制（代码级与知识级分开）

Hermes（NousResearch 的 hermes-agent，官方定位 “The self-improving AI agent”）的模块化同样写进了文档，而且分了两条线，这正好呼应前面的分层论点：

插件（plugin，代码级扩展）：三种发现源，~/.hermes/plugins/（用户级）、.hermes/plugins/（项目级）、pip entry points（来源：官方 Architecture 文档）。插件通过 context API 注册 tools / hooks / CLI commands（ctx.register_*() 一族函数）。还有两类专门插件：memory providers 与 context engines，且都是单选的（single-select），选一个记忆后端、选一个上下文引擎，切换就是改配置。
技能（skill，知识级扩展）：走 ~/.hermes/skills/ 的 agentskills.io 文件夹机制，可外链目录；hermes skills tap add owner/repo 可以把任意 GitHub 仓库当私有技能源，hermes skills install <url> 直接装 URL 上的 SKILL.md，技能可以搜索、可以共享、可以跨产品移植（来源：官方 Skills 文档）。

换句话说，Hermes 刻意把“代码级扩展（plugin：工具、钩子、记忆后端、上下文引擎）”和“知识级扩展（skill：SKILL.md + references）”拆成两套机制，plugin 管“Agent 能做什么”，skill 管“Agent 做某类事时有多专业”。两者都支持按需装卸与更新，都不需要动核心循环。

图 4-3 · Hermes 的“代码级插件 + 知识级技能”双轨扩展：一切按需装卸，核心循环不被打扰

4.4 实操回答：怎么布置、怎么增删模块、怎么验证

DSH（DeepSeek Harness）

布置：npx @deepseek-ai/dsh web（需要 Node.js），默认起 Web UI http://127.0.0.1:3080；在 Settings → Models 填 API key（DeepSeek 官方或任意 OpenAI 兼容端点）。（来源：DSH 官方仓库 github.com/deepseek-ai/deepseek-harness 的 docs/）
增删模块：加 bundle / 加一行 patch；删模块 = 从 profile 里去掉那行插件。分层：bundle → profile patch → home patch → --patch 命令行覆盖。
验证：dsh --profile web --dump-config 打印实际启动的配置树，每一行都可被你自己的 patch 替换；运行中动态装卸走 Dynamic Cordis（cordis_define → run → stop → undefine）。

Hermes（NousResearch）

布置：Windows 原生 PowerShell 一行 iex (irm https://hermes-agent.nousresearch.com/install.ps1)；Linux/macOS/WSL2 用 curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash。装完 hermes 开始聊，hermes setup 走完整向导。（来源：hermes-agent GitHub README，支持 Native Windows）
增删模块：hermes model 切换模型（无代码、无锁定）；hermes config set memory.provider <name> 换记忆后端；插件放进三个发现源之一；技能用 hermes skills tap add / install。
验证：hermes doctor 诊断安装与环境；hermes config get 查看配置；换记忆体后 /reset 让新工具生效（Mnemosyne-OS README 就是这么写的：配好 provider → reset → 14 个 mnemosyne_* 工具出现）。

🐾 结论（本章一句话）：DSH 与 Hermes 都证明，“布置”从来不是一次性动作，而是一组可随时增删、可热更新、可验证的模块化操作。差异只在抽象层级：DSH 把“一切皆插件”做到了机制层（连循环都可换），Hermes 把“按需装卸”做成了产品功能（配置项 + 双轨扩展）。两边都在告诉你同一件事：外设越可插拔，驾驭工程越省钱。

5查漏补缺：分专业、分赛道的驾驭工程全景图

上面点名的概念只是冰山一角。真正的“驾驭工程”有十几个专业赛道，本喵把它们全部摊开：每个赛道给“解决什么问题 / 典型工具 / 距离档位 / 主流玩法”。先看总览，再逐个拆。

图 5-1 · 驾驭工程 13 赛道总览：全部围绕同一个内核（一段代码调 API）

赛道 ① · Prompt 工程

必要（技巧层正在退化）解决什么：一次调用里，用 messages/system 告诉模型“你是谁、要干嘛、输出长什么样”。

典型工具：Anthropic Prompt Engineering 文档（docs.anthropic.com）、GEPA 自动演化（github.com/gepa-ai/gepa，arXiv:2507.19457）、Guidance/Outlines 结构化输出。

主流玩法：Anthropic 官方建议从 minimal prompt + 最强模型起步，按失败案例加指令与少量 canonical few-shot；prompt 从“手写咒语”变成“可优化、可版本化的代码对象”；输出约束交给 JSON Schema / function calling，不再靠 prompt 求情。

赛道 ② · 上下文工程

增强解决什么：多轮循环里，决定每一轮往有限的上下文窗口塞哪些 token。Anthropic 称之为对抗 context rot（上下文越长，召回越差）。

典型工具：Anthropic《Effective context engineering for AI agents》（anthropic.com/engineering/effective-context-engineering-for-ai-agents）、Hermes 双重压缩（hermes-agent.nousresearch.com/docs/developer-guide/context-compression-and-caching/；主压缩是 Agent 内的 ContextCompressor（默认 50% 阈值、可配置），网关侧另有一道 85% 的会话卫生安全网，压缩器可插拔）、CLAUDE.md/AGENTS.md hybrid 注入。

主流玩法：四件套，Compaction（摘要后开新窗口）、Structured note-taking（写窗口外 NOTES.md）、Sub-agent（脏上下文隔离）、just-in-time 检索（用 glob/grep 按需取数）；老工具结果一旦可重查就丢弃。

赛道 ③ · 记忆工程 / RAG

增强（语义缓存为锦上添花）解决什么：让无状态的 API 调用跨会话、跨用户积累知识。

典型工具：Letta/MemGPT（letta.com，三层记忆：core/archival/recall）、Mem0（github.com/mem0ai/mem0）、pgvector/Chroma/Qdrant/FAISS、GPTCache（github.com/zilliztech/GPTCache）、OpenAI ChatGPT Memory、Anthropic Memory（anthropic.com/news/memory）。

主流玩法：生产标准收敛为 hybrid（dense 向量 + BM25）→ RRF 融合（k=60）→ cross-encoder rerank top-20（来源：Qdrant 官方指南）；记忆生命周期（写入 → 蒸馏 → 衰减 → 遗忘）工程化；官方正在把 memory 内化成产品功能（ChatGPT saved memories、Anthropic project memory + 开发者 memory tool）。

赛道 ④ · 工具与函数调用工程

必要解决什么：让模型的“决定”变成本地代码的执行动作，形成“思考 → 调用 → 观察 → 再思考”闭环。没有它，Agent 只会聊天。

规范要点：OpenAI tools[]（JSON Schema + tool_choice auto/none/强制 + parallel_tool_calls）；Anthropic 顶层 tools[]，官方把“写极其详细的 description”列为工具性能最重要因素（anthropic.com/engineering/writing-tools-for-agents）。

主流玩法：SDK 从类型注解/Pydantic/Zod 自动抽 schema；strict 校验默认开启；并行工具调用拉长耗时查询；强制工具调用把多步流程钉在固定路径。

赛道 ⑤ · MCP 生态

增强解决什么：function calling 的每个工具都要手写 schema 与客户端，N 个 Agent × M 个工具适配器爆炸，MCP 用一套 JSON-RPC 协议把工具/资源/prompt 的暴露与发现标准化。

现状（2026-09）：spec 版本 2026-07-28；transport 只剩 stdio（本地默认）与 Streamable HTTP（2025-03 取代 HTTP+SSE，支持 OAuth）；官方 Registry（registry.modelcontextprotocol.io）+ reference servers（Fetch/Filesystem/Git/Memory 等）。

定位（插电板判断）：MCP 不碰模型、不改 function calling，它在 host 层发现 server、把工具转成 host 原生 schema、照常喂给模型，模型完全感知不到。单 Agent 是增强，接几十个 SaaS 的团队是效率杠杆。

赛道 ⑥ · 技能工程 Skill

锦上添花解决什么：工具解决“能做什么”，技能解决“怎么做某类事才算专业”。把领域 know-how 打包成可发现、可装载、可自主调用的单元。

典型工具：agentskills.io 开放标准（SKILL.md：name ≤64 字符、description ≤1024 字符，已被多家 Agent 产品兼容）、Anthropic Agent Skills（docs.claude.com，标准发源地）、DSH skills 合约（SKILL.md 丢进 ~/.agents/skills）、Hermes skills（/learn 自主创建、skills tap add owner/repo 把 GitHub 仓库当技能源、信任分级）。

主流玩法：progressive disclosure，先只加载 SKILL.md 索引（YAML frontmatter：name ≤64 字符、description ≤1024 字符），用到再拉 references/；Hermes 已实现“复杂任务跑通后自动把路径写成 SKILL.md”的学习循环。

赛道 ⑦ · 多智能体编排

锦上添花解决什么：单 Agent 上下文有限、一个 prompt 难以同时扮演“严谨评审 + 动手实现 + 测试”。把任务拆给多个独立上下文、独立工具集的子 Agent。

两种源头：MoA（Mixture-of-Agents，arXiv:2406.04692，分层 proposer → aggregator，用模型堆模型）；Orchestrator–Worker / subagent 委托（OpenAI Agents SDK handoffs、Anthropic subagent、Hermes delegate_tool）。

框架现状：LangGraph（生产首选，图式状态机 + checkpointing）；CrewAI（~52.8k★，原型快、生产抽象薄）；AutoGen（~58.7k★，2025 年底进入 maintenance，微软官方推荐迁移到 Microsoft Agent Framework）；OpenAI Swarm 已被 Agents SDK 取代。

赛道 ⑧ · 模型路由与网关

增强解决什么：统一 OpenAI 协议入口、按成本/延迟/可用性选后端、429/5xx 自动降级、按项目/用户做 key 鉴权与花费统计。

典型工具：LiteLLM Proxy（docs.litellm.ai，100+ provider 统一 OpenAI 格式 + fallback + 虚拟 key + 预算）、OpenRouter（openrouter.ai，托管聚合 + Auto Router 按任务类型选模型 + cost_tier）、New API / One-API（约 36.9k★，国内流行的渠道轮询 + 分组配额 + 计费面板）。

主流玩法：自托管派 LiteLLM/New API 统一内网出口；小团队一个 OpenRouter key 打天下；云厂商下场做托管 AI Gateway。

赛道 ⑨ · 运行时与生命周期管理

增强（多轮/长任务时逼近必要）解决什么：内核只是“发一次请求”，真实 Agent 是多轮、长时、可能崩的循环，会话状态、断点续跑、超时重试、崩溃不重复烧 token。

典型机制：LangGraph Checkpointer（SQLite/Postgres 存 StateSnapshot，thread_id 游标，time-travel + interrupt 等人审）；Durable Execution（Temporal/Restate，崩溃后日志重放，已完成的 LLM 调用不重复计费）；Hermes SessionDB（~/.hermes/state.db，SQLite + FTS5 作 canonical 会话库）。

主流玩法：durable execution 从黑话变成各家 SDK 一等公民；重试只对 429/5xx 做指数退避 + jitter；Saga 补偿用于多步部分失败。

赛道 ⑩ · 评估与可观测性

锦上添花（生产环境增强）解决什么：内核是黑盒，Eval 回答“输出对不对”，trace/日志回答“刚才到底发生了什么”。没有它，改 Prompt 就是玄学。

典型工具：promptfoo（YAML 驱动 evals，trajectory 级断言 + 红队用例）、DeepEval（code-first，60+ 指标）、LangSmith（托管 trace，接 OTLP）、Arize Phoenix / Langfuse / Helicone（开源自托管）、OpenTelemetry GenAI 语义约定（gen_ai.operation.name 等，已被 Azure/AWS/LangSmith/Phoenix 共同采纳）。

主流玩法：eval 从“端到端打分”转向 trajectory 级评估（把整条决策链当被测单元）；trace 后端收敛到 OTLP 避免厂商锁定。

赛道 ⑪ · 部署与自托管

增强（可选路线）解决什么：数据不出内网、跑在边缘/笔记本、量大到自建 GPU 更划算，把模型变成 OpenAI 兼容 endpoint，前面挂鉴权/配额/限流。

典型工具：llama.cpp + GGUF（Q4_K_M 把 7B 从 ~14GB 压到 ~4GB，CPU/Mac 唯一现实推理格式）、Ollama（单二进制，内置 /v1 兼容端）、vLLM（PagedAttention + continuous batching，数据中心吞吐型，2026 已支持 GGUF 与 Apple Silicon）。

主流玩法：分层选型，个人/边端 Ollama，团队高并发 vLLM，CPU/Mac llama.cpp；前面统一挂网关做 key/配额/限流。DSH/Hermes 接自定义 OpenAI-compatible endpoint 只需把 base_url 指过去，协议已统一、接入成本近零。

赛道 ⑫ · 安全与合规

增强（一旦有写权限/联网，逼近必要）解决什么：内核一旦带工具，就从聊天机器人变成“可执行代码的进程”，防提示注入、限制工具最小权限、危险动作设审批门、数据隔离与沙箱。

典型机制：OWASP Top 10 for LLM Apps 2025（LLM01 仍是提示注入，官方缓解清单见 genai.owasp.org）；Claude Code 权限模式（Manual 逐动作询问 → 2025-10 转向 OS 级沙箱）+ Agent SDK 四层控制（permission modes / canUseTool 回调 / hooks / settings.json）；Hermes 的 Tirith / command approval（危险命令触发 once/session/always/deny 四选项审批门）。

主流玩法：从“逐次弹确认”（烦人、用户习惯性点 always）转向“OS 级沙箱 + 工具白名单 + 最小权限挂载”；检索内容一律当 DATA 不当 COMMAND，协议层用独立上下文窗隔离。

赛道 ⑬ · Workflow 与 Agent 的边界

必要（设计层，不是组件而是起点）解决什么：写核心代码之前的第一架构决策，流程路径是预先定死（DAG：prompt chaining / parallelization / routing / orchestrator-worker / evaluator-optimizer），还是让模型运行时自己选下一步（agentic loop）。

权威判据：LangChain 官方《Workflows and agents》（docs.langchain.com/oss/python/langgraph/workflows-agents）：“Workflows have predetermined code paths… Agents are dynamic and define their own processes and tool usage”；2026 行业明显回摆，能用确定性 DAG 就不用自主 loop，只在路径真不可预知的节点嵌一个小 agent（mix deterministic logic with agentic behavior）。

对照实证：DSH 用“运行模式”表达这条光谱，Standard / PTC（Code Mode SDK，模型写一段 TypeScript 链式调用）/ Minimal / Creation，都是配置而非新代码；Hermes 的 execute_code 把多步流水线压成单次推理调用，是“把 Agent 变回确定性程序”的另一种路线。

5.2 生态速览：2026 年的 Agent 江湖

玩家	代表性动作	对“驾驭工程”的含义
Anthropic / Claude Code	Agent Skills（agentskills.io 发源地）、subagent、权限模式 + OS 级沙箱、hooks.json	把“技能可移植”和“安全默认”做成产品功能，工程规范向标准演化
OpenAI	Agents SDK（原 Swarm 转正）、Structured Outputs、ChatGPT Memory 内化、AutoGen 并入 Microsoft Agent Framework	官方把 memory / 工具 / 编排“收编”进 SDK，外设开始被内核化
Google / 开源社区	Gemini 百万级上下文窗口、KV 缓存军备竞赛；MCP registry、Letta/Mem0、vLLM 生态	长上下文 ≠ 免费午餐（§8 会展开“上下文腐烂”）；开源协议层正在形成

表 5-2 · 生态速览：内核在进化，外设在标准化，两条线同时在跑

来源：Claude Code 文档（code.claude.com/docs/en/permission-modes）；OpenAI Agents SDK（openai.github.io/openai-agents-python）；LangChain workflows-agents 文档；MCP registry（registry.modelcontextprotocol.io）。

🐾 小结：13 个赛道没有一个是“可选项=可省略”，它们只是“按场景决定要不要上、以什么形态上”。选型口诀：先内核（一段代码调 API）→ 再必要层（Prompt/循环/工具分发/状态）→ 最后按需加外设（记忆/MCP/Skill/网关/观测/安全），每加一层都问一句：它能被单独拆掉吗？

5.3 顺带算一笔账：一个回合的钱，到底花在哪

上面十三个赛道聊的都是"该不该上"，但工程决策最后总要落到钱和延迟上。本喵在自己机器上量了一组真实数据，统计口径写在文末来源里，数字可以直接复算：

115

次 API 调用
只为完成一次任务

2124万

送进模型的
token 总量

13万

模型真正
吐出来的字

422

人敲进去的字符（占不到 0.24%）

缓存读 2093 万未命中输入 18 万模型输出 13 万

图 5-3 · 一次真实会话的 token 构成（Hermes state.db；最近 30 个 api_call_count>=5 的会话取中位数）：那一根几乎占满整条的，就是被反复重发的上下文

这组数字解释了前面所有"非必要但非常需要"的组件为什么值钱，也解释了三条硬工程纪律：

前缀必须稳，本机这组账里，缓存读与未命中输入差了两个数量级；前缀一动，全部按未命中价重算，成本当场翻十倍。
垃圾进上下文就是花钱，每一轮都把系统提示、工具 schema、历史重新发一遍；所以"工具越加越多"和"历史永不清理"都会直接变成账单。
压缩要早、要有节制，到窗口快满才压缩，等于前面几百次调用一直在为噪声付费（这就是赛道 ② 存在的理由）。

图 5-4 · 一百多次调用之后：账单长什么样，取决于每一轮你往窗口里塞了什么

6实战经验：从布置到增删，再到自研记忆体的真实案例

理论讲完了，来点干货。这一章讲三件事：怎么把 DSH / Hermes 布置成“可增删的积木系统”；本喵主理人自研的 Mnemosyne-OS（记忆宫殿 OS）和 noah-gen3-type2 是怎么做出来的、审计结论长什么样；以及从这些实战里能提炼出什么心法。

6.1 布置总流程：永远先内核，后外设

第 0 步（半小时）：写一段代码调 API，跑通一个回合。别急着装任何框架。这是你的“内核基准线”。
第 1 步（半天）：加工具分发，定义 2~3 个函数（读文件、搜索、跑命令），把 tool_calls 接起来。恭喜，你已经有最小 Agent 了。
第 2 步（可选）：换 harness，装 DSH 或 Hermes（命令见 §4.4），把内核“托管”进去。此时内核没变，只是换了个外壳。
第 3 步（按需）：逐个加外设，记忆体（一个 memory.provider 配置）、MCP server（配置文件加一行）、Skill（丢一个 SKILL.md 目录）。每加一个，跑一遍基线任务确认没把内核弄坏。
第 4 步（常驻）：建立验证习惯，dsh --dump-config / hermes doctor / 一条 eval 用例。外设越加越多时，这条“回归基线”是你唯一的救生索。

💡 这条流程本身就是 §3/§4 的落地：内核先跑通（耦合点收敛）→ 外设按需挂（模块化装卸）→ 验证基线（影响半径可控）。顺序反了，后面的每一步都是灾难。

6.2 案例一：Mnemosyne-OS「记忆宫殿 OS」，一个自研记忆体的真实状态

一句话定位：不是向量数据库、不是 RAG 流水线，而是一套把记忆当作“一等系统”来管理的记忆宫殿 OS，写入、蒸馏、老化、遗忘、复现全生命周期，自托管、Hermes 原生。

当前实况（以 GitHub 仓库为准：仓库里的 VERSION 已是 v8.0.0）：技术栈已从早期“SQLite + 单 Python 依赖”演进为 PostgreSQL 16 + pgvector 1024d HNSW + FastAPI（50+ 端点）；早期白皮书 v5.2 的版本号/性能数据已过时，一切以仓库 README 与代码为准。主要机制：

宫殿分类体系（taxonomy）：当前 README 实况为 7 翼 × 20 房（早期版本与主理人口径曾记 9 翼，版本间有差异，以仓库实况为准），K 知识 / N 网络 / D 开发 / O 运维 / A 资产 / P 人 / I 想法。
档号制（archive-no）：每条记忆一个“图书馆索书号”，如 K·NET·PROXY·2026-0007，位置即编号，不再把一切倒进扁平向量堆。
三通道召唤（3-channel summon）：① Name 精确命中（<100ms）→ ② Guide 分类导航（~200ms）→ ③ Resonate 向量模糊（~300ms），一次调用三种通道。
三厅分工 + 药柜：研究厅（对话→结构化事实抽取，DeepSeek 双模型蒸馏）→ 档案馆（分类 + 写 tome card）→ 图书馆（检索），高频繁用记忆进“药柜”常驻。
保留层级：permanent（规则/身份/红线，永不过期）/ long（知识/项目，极慢衰减）/ short（90 天自动清理），热度衰减不是摆设。
Hermes 原生：Memory Provider 提供 14 个工具（含 mnemosyne_palace_summon），hermes config set memory.provider mnemosyne → /reset → 工具即出现；会话结束自动触发同步 + 事实抽取。
注入调度器（v7.7.0）：技能翼（procedural memory）+ 场景感知注入计划（/api/v1/injection/plan）；嵌入层并发 + LRU 缓存 + 指数退避重试，冷批次提速 7.7×。
MCP bridge（v7.8.2 起契约修复） + WIKI 知识库：向量 HNSW + BM25 + RRF 融合，可选 rerank（doubao 重排）与 1-hop 知识图谱扩展；20 条查询的 eval（v7.5）：precision@3 100% / recall@3 98.3% / MRR 1.0。
端云同步：WSL 离线时本地 SQLite 缓存，上线后静默推送到 PostgreSQL，边缘与云端各司其职。

图 6-1 · Mnemosyne-OS 记忆宫殿管线（据 v7.8.x README 实况绘制）

图 6-2 · 记忆生命周期闭环：Mnemosyne 把“遗忘”当成一等公民，而不是 bug

诚实审计对照：一次只读审计发现了什么，版本演进修正了什么

2026 年早些时候，我们对 Mnemosyne-OS 做过一次只读深度审计（当时为 v7.5~v7.7 区间），发现过几处硬伤。拿出来讲不是为了自黑，而是展示“经得起检验”的态度，顺便看看版本演进有没有把它修好（对照依据：仓库 CHANGELOG / README 实况）：

审计发现（v7.5–v7.7 区间）	后续版本修正（以仓库实况为准）	状态
记忆写入非原子，异常时可能留下半条记录	v7.8.1 起写入时做 tokenization（消除 BM25 24h 盲区）；新增 23 个契约测试（v7.8.4 “+23 contract tests”）	逐步加固
软删除无 GC，僵尸数据堆积	v7.8.0 移除 8 个死资产（memory_chunks / pointer / conversation_messages / halls / tools / projects / response / tome_links），做“抽屉化”整理	已清理
“RRF 融合”名不副实（当时实现非标准 RRF）	v7.8.0 起明确 real BM25；WIKI 检索默认 RRF fusion（README 明确写出），并可叠加 rerank	已对齐
早期 README 的 20 维映射 / 9 翼口径与实现有出入	v7.0 重写为宫殿体系（当前 7 翼 × 20 房 + 档号 + tome cards），README 与代码同步更新	口径统一

表 6-1 · 审计→修复对照：开源项目的正确姿势是“敢让人查、查完能改、改完有版本记录”

v6.0.0 2026-08-02 · 概念模型重构，TMT 管线修复

v6.2.0 2026-08-05 · 认知热度引擎：命中加热 / 差分衰减 / 蒸馏热度

v6.4.0 2026-08-05 · 事实抽取：对话 → 结构化个人事实

v7.0.0 2026-08-06 · 🏰 魔法记忆宫殿：分类 + 档号 + tome cards + 三通道召唤 + 保留层级

v7.1.0 2026-08-09 · 抽屉化记忆：临时×时间双轨 + 遗忘候选

v7.7.0 2026-08-18 · 注入调度器：技能翼 + /injection/plan + 嵌入优化 7.7×

v7.8.0 2026-08-18 · 瘦身：移除 8 个死资产，real BM25（响应此前“RRF 名不副实”审计）

v7.8.1 2026-08-24 · 写入时 tokenization（消除 BM25 24h 盲区）+ MCP 2.0 适配

v7.8.4 2026-09-24 · 归档质量修复（消息不再被截断）+ 报告卡片 + 23 个契约测试

v8.0.0 2026-09 · 记忆宫殿 OS 主线：仓库 VERSION 已到 8.0.0（README 列表待同步），这正是心法 ④ “文档会过时、代码才是实况”的活例子

图 6-3 · Mnemosyne-OS 版本演进时间线（据 CHANGELOG/README 实况）：一个月内从重构到宫殿化再到工程加固

来源：github.com/gymaira1990-jpg/Mnemosyne-OS（README、CHANGELOG，2026-09 实况）；审计结论为本喵早前一次只读研究的记录。

6.3 案例二：noah-gen3-type2（诺亚三代·二型），从“爆炸”里长出的通用认知架构

一句话定位：从“原铸诺亚”数万轮实战对话中萃取、解耦出的通用型 AI 认知架构（MIT 开源，独立于任何框架/供应商），它的 README 毫不避讳：上一代“原铸诺亚·二代一型”标注“💥 此版本已经爆炸，仅供参考”。这份诚实本身就值一个赞。

01 上下文管理组装系统（生产就绪）：抽屉级联三层管线，宣称 38.5:1 压缩比、零悬崖（context cliff）、100% 用免费模型做压缩，正是 §5 赛道 ②（上下文工程）的实战化，而且把“付费模型做压缩=花冤枉钱”当成了第一原则。
02 Mnemosyne 记忆宫殿（🔄 已独立）：已从本仓库独立为 Mnemosyne-OS 产品，见 6.2。
03 认知 AI 底座（方案阶段）：基础 AI 推理能力底座，设计完成。
04 原铸诺亚·二代一型（已爆炸，仅供参）：7 个 NCP 模块、15,000+ 行生产代码的完整诺亚实例，失败的教训被当作资产保留。
05 工具集（生产就绪）：纯 stdlib CDP 浏览器控制 + 统一工具管理 CLI + 搜索管线。
06 诺亚核心·模型管理与对话面板（生产运行）：pip install 即跑的 LLM 模型管理中心，CLI + Web 双门。

它解决的七大痛点（仓库 README 自述）：跨会话失忆 / 纠正了下次又犯 / 活跃任务丢失 / 寒暄噪音占上下文 / 历史方案不记得（重复造轮子）/ 付费模型做压缩浪费钱 / Agent 重启记忆就丢，七个问题，恰好就是这篇在说的“驾驭工程”要回答的全部问题。

来源：github.com/gymaira1990-jpg/noah-gen3-type2（README，2026-09 实况）。

6.4 心法：从这些实战里能拿走什么

① 先内核，后外设

Mnemosyne 再华丽，Hermes 再全能，都改变不了“记忆最终要拼回 prompt、工具最终要走 tool_calls”的事实。先把 20 行核心代码写到无懈可击，再谈外设。

② 外设必须可拆

DSH 的 patch、Hermes 的 provider、Mnemosyne 的 env 换模型，好的外设都遵循同一原则：装卸只动配置，不动内核。装不上的外设，将来也拆不下来。

③ 验证基线是命根子

加一个外设、改一版 Prompt、升一次框架，每次都跑一遍基线任务。没有基线，你永远不知道是哪个零件把 Agent 搞笨的（想想 §8 会讲的“上下文腐烂”）。

④ 文档会过时，代码才是实况

Mnemosyne 白皮书 v5.2 已过时，实况在 GitHub；DSH 明确写着 “THERE WILL BE COMPATIBILITY-BREAKING CHANGES”。读文档要标日期，下结论要拿版本号。

⑤ 诚实迭代，把失败当资产

noah-gen3-type2 留着“已爆炸”的二代一型，Mnemosyne 把审计硬伤写进 CHANGELOG。能经得起别人审计的工程，才配叫工程。

⑥ 一切回到“一段代码调 API”

不管外设铺多厚，最后的验收标准永远是：它有没有让输出更 OK、让任务更好地完成。没有，就拆。

7常见误区与 FAQ：十个最容易踩的坑

都是社区里高频出现的争论。本喵用全文的论据直接回答，每个都标了来源。

误区 1：“MCP 是 Agent 的必备组件，不接 MCP 就不专业”

不是。单 Agent 手写工具分发完全成立，MCP 只是把工具工程“协议化”（§5 赛道 ⑤）。它对单 Agent 是增强，对要接几十个 SaaS 的团队才是效率杠杆。判断标准：你手写的适配器数量开始爆炸了吗？没有就别上。（来源：modelcontextprotocol.io；MCP “插电板”定位见 §5 赛道 ⑤）

误区 2：“记忆体越重越好，RAG 堆得越全越聪明”

不是。记忆也是噪声源，检索出来的内容最终要拼回 prompt，拼回去的噪音会参与注意力计算，累积成“上下文腐烂”（§8 详述）。记忆工程的重点是生命周期（写入 → 蒸馏 → 衰减 → 遗忘 → 复现）与检索过滤，不是容量。Mnemosyne-OS 的档号制、保留层级、药柜，都是在对抗“记忆变噪声”。（来源：github.com/gymaira1990-jpg/Mnemosyne-OS；主理人的论文《记忆的困境》，DOI 10.5281/zenodo.20433184）

误区 3：“上下文窗口够大，就不需要 RAG / 记忆 / 压缩了”

Anthropic 官方明确说：“等更大窗口”不是答案，任何窗口都受 context pollution 影响，长上下文反而放大噪声累积。主理人的论文的 CRI 模拟显示：超过 ~15 轮或 ~32k token 时，有效信息利用率跌破 40%，注意力熵从 3.2 跌到 1.1 nat（作者自述实验）。长窗口 ≠ 免费午餐，策展（context engineering）才是。（来源：anthropic.com/engineering/effective-context-engineering-for-ai-agents；my.g-cat.cn/experience/memory-dilemma.html）

误区 4：“框架套框架，越多越保险”

不是。框架是“外设的收纳盒”，两层框架嵌套 = 两套耦合契约 = 双倍升级成本。选框架的判据只有一条：它允许你多大程度替换/卸载它的零件（DSH 在这点做到了极端，连循环都是插件）。选一个让你“能换零件”的，别选一个让你“感恩”的。（来源：DSH 官方仓库 docs/；akillness.github.io 拆解）

误区 5：“多智能体 = 更聪明，规模越大越强”

不是。多智能体只是组织方式，不是智力放大器。MoA 论文证明了“用模型堆模型”在基准上有收益（6 proposer 开源模型在 AlpacaEval 2.0 上 65.1% 超 GPT-4 Omni 的 57.5%），但代价是多次调用、成本与延迟线性涨。判据：单上下文装不下 / 需要真并行 / 需要独立评审，满足才上。90% 的单身工具型 Agent，一个 orchestrator 循环 + 几个 subagent 就够。（来源：arXiv:2406.04692；hermes-agent README “Spawn isolated subagents for parallel workstreams”）

误区 6：“Skill 就是复杂一点的 Prompt，没用”

Skill 确实是“更好的 prompt + 更规矩的流程”，但它解决的是可发现、可装载、可版本化、可共享：agentskills.io 让技能跨产品移植；Hermes 甚至能在复杂任务跑通后自主把路径写成 SKILL.md（learning loop）。它的价值是省 token（progressive disclosure 只加载索引）、沉淀经验、跨项目复用。是锦上添花，不是骗局。（来源：agentskills.io；hermes-agent.nousresearch.com/docs/user-guide/features/skills）

误区 7：“自托管本地模型一定更省钱”

不一定。社区共识（未见权威 2026 单价对比）：中小流量打云 API 更便宜（你要付 GPU 折旧、电费、运维人力），稳定大流量 + 数据敏感才回本。自托管的真正卖点是数据不出内网，不是省钱。而且 2026 年协议已统一，Ollama/vLLM 都提供 OpenAI 兼容端点，DSH/Hermes 接本地模型只是改 base_url。（来源：github.com/ggerganov/llama.cpp；ollama.com；docs.vllm.ai；社区说法见 §5 赛道 ⑪）

误区 8：“缓存命中率高 = 系统质量好”

可能反了。主理人的论文《记忆的困境》指出：KV 缓存把历史噪声留存在注意力里，形成“噪声吸引子”，命中率越高、上下文越长，越容易“降智”；其效率扭曲系数 E 在命中率超 70% 后反而下降；并提出“纯净模式”按任务收费以对齐激励（作者自述实验与方案）。另一个现实证据：DeepSeek API 缓存命中输入价 0.2 元/百万 tokens，未命中 2 元/百万 tokens（差 10 倍），价格在“劝你重复”。（来源：my.g-cat.cn/experience/memory-dilemma.html，DOI 10.5281/zenodo.20433184）

误区 9：“布置 DSH / Hermes 是一锤子买卖，配好就完事”

不是（§4 全章就是为这个问题写的）。DSH 是“无特权内核”的插件树：加模块 = 叠一层 patch，删模块 = 去一行，运行中还能动态装卸（Dynamic Cordis）；Hermes 是三发现源插件 + 双轨扩展（plugin/skill），memory.provider 一行配置换记忆后端。布置是起点，模块化更新与按需装卸才是机制层的常态。（来源：DSH 官方仓库 docs/；hermes-agent.nousresearch.com/docs/developer-guide/architecture）

误区 10：“提示注入是模型的事，我管不了”

工程能管，而且必须管。OWASP LLM Top 10 里 LLM01 仍是提示注入，官方缓解清单：分隔可信指令与不可信数据、对工具调用做确定性校验、工具最小权限、高风险动作人审、红队测试。Hermes 有 Tirith / command approval（危险命令给 once/session/always/deny 四选项），Claude Code 已从逐次询问转向 OS 级沙箱。原则就一句：检索来的内容一律当 DATA，不当 COMMAND。（来源：genai.owasp.org/llmrisk/llm01-prompt-injection；code.claude.com/docs/en/permission-modes）

8未来趋势：协议层标准化与记忆层标准化（查漏补缺的最后一环）

“驾驭工程”不是静止的。内核（Transformer/模型）在迭代，外设（协议/记忆）也在迭代，而且两条线正在互相塑造。这一章讲清楚：协议层会怎么标准化、记忆层会怎么标准化、以及一个真实的“自研协议层”长什么样。

8.1 双线迭代：Transformer 在变，驾驭工程也在变

内核侧：模型本身在吸收“外设”

长上下文军备竞赛：Gemini 百万级窗口、各家数十万 token 标配，但 Anthropic 官方明确“更大窗口不是答案”（§7 误区 3）。
官方 memory 内化：OpenAI ChatGPT Memory（saved memories + 历史引用）、Anthropic 开发者 memory tool（file-based、数据存你自己服务器），“记忆”正在从第三方外设变成官方功能。
结构化输出 / 更强指令遵循：JSON Schema 约束、Structured Outputs，让 Prompt 技巧层持续退化（§5 赛道 ①）。

外设侧：工程反而更“贵”了

上下文腐烂成为架构级问题：KV 缓存把历史噪声留存在注意力里（§8.3 展开），长上下文越多，策展（context engineering）越重要，Anthropic 的四件套（compaction / note-taking / subagent / just-in-time retrieval）就是这个趋势的产品化。
安全默认化：Claude Code 从逐次询问转向 OS 级沙箱，Hermes 有审批门，工具越强，护栏越刚。
可观测性与 eval 标准化：OTel GenAI 语义约定成为跨厂商通用语（§5 赛道 ⑩）。

8.2 协议层标准化：MCP、A2A，以及“自研协议层”的定位差异

2025–2026 最大的结构性变化是协议层开始成型。协议决定“谁用什么格式和谁说话”，是驾驭工程里最“牵一发动全身”的契约面（呼应 §3 的强耦合点）。目前有三类定位完全不同、经常被混为一谈的协议：

协议	回答的问题	交付颗粒度	模型感知	典型代表
MCP （Model Context Protocol）	Agent 客户端 ↔ 外部能力服务器（工具/资源/prompt）如何发现与调用	工具函数级	模型无感（host 层转换 schema）	Anthropic 发起；registry + reference servers；Hermes/DSH/Claude 全面接入
A2A （Agent2Agent）	Agent 与 Agent 之间如何互操作、协作、交接任务	Agent 交互级	Agent 之间感知	Google 发起（2025-04 开源）；OpenAI 的 MCP/A2A 双协议布局
Goldshine Protocol （金铲铲协议，自研案例）	去中心化“能力交付网络”：把 AI 能力作为可注册、可路由、可结算的服务交付	自治智能体级（ASU）	能力消费者只认“交付物”，不认实现	GCAT/DeepSeek，v1.5.2，CC BY-SA 4.0（作者自述设计白皮书）

表 8-1 · 三类协议的定位差异：工具协议 vs Agent 互操作协议 vs 能力交付网络，别用一把尺子量三个东西

Goldshine Protocol 拆解（以下均为作者在协议白皮书中自述的设计，未经独立工业验证，引用时请注意口径）：

交付单位升级：把能力交付的颗粒度从“工具函数级”升级为“自治智能体级”，ASU 五元组 E/D/W/M/I（底座引擎 / 领域增强层 / 工作流引擎 / 记忆系统 / 协议适配层）。论文对 OpenAI Function Calling、Anthropic MCP 的“交付零件”局限做了对比批评（作者观点）。
兼容 OpenAI 协议：请求格式兼容 Chat Completions API，附加 6 个扩展字段（task_id / session_id / capability_tags / delivery_schema / callback_url / max_budget），支持同步、SSE 流式与异步 202 三种交付方式。
物理级记忆隔离：容器隔离 + 命名空间隔离解决上下文污染，宣称把注入泄漏风险从 10⁻² 量级压到“容器逃逸级”10⁻⁶（作者宣称数据，未独立复现）。
双层注册发现：L1 DHT 静态注册层 + L2 /health 实时探测；三级部署成本分级（L1 独立部署 / L2 共享底座 / L3 按需唤醒）；多维信誉 + 质押惩罚 + 分层仲裁的经济体系。
语义本体：16 个一级领域、去语言化符号交互，意图用“领域+能力”代替自然语言协商。

来源：my.g-cat.cn/experience/goldshine-protocol.html（v1.5.2，2026-06，CC BY-SA 4.0；论文 DOI 10.5281/zenodo.20789868，Zenodo 页面被 robots.txt 拦截，正文来自官网子页）。定位差异中的 MCP/A2A 事实见 modelcontextprotocol.io 与 Google A2A 发布资料。

8.3 记忆层标准化：从“记忆崇拜”到“通信本位”

记忆是驾驭工程里最热、也最容易被神化的外设。2026 年的两个方向正在把记忆从“玄学”推向“标准”：

产品化内化：OpenAI 把 memory 做成 ChatGPT 内置功能（可看/可删/可关），Anthropic 提供开发者 memory tool，官方把记忆的生命周期管理（谁存、存多久、谁能看）定义成产品契约。
架构级批判：用户（GCat/0101）的经验分享论文《记忆的困境：大模型KV缓存机制引发的“上下文腐烂”现象及其系统性重构》（DOI 10.5281/zenodo.20433184，作者自述实验，非同行评审）系统论证了一个反直觉结论：KV 缓存不是免费午餐。核心论据：

关键论点	作者给出的依据（自述实验/案例）
“上下文腐烂”三阶段动力学	噪声锚定 → 噪声吸引子形成 → 信息新物种排斥；注意力权重向历史噪声倾斜，新需求被边缘化
量化模拟（Llama 3-70B，20 轮）	15 轮 / 7.4k token 后有效信息利用率跌破 50%，25 轮仅剩 22%；注意力熵 3.2 → 0.8 nat
5 模型 CRI 对比	GPT-5.2 / Claude 3 Opus / GLM-5 / Llama 3-70B / DeepSeek-V3 在 25 轮 CRI 均 >0.7，问题普遍存在
2026 两大实证事故	Claude Code 28 天缓存故障（缓存读取率 97–99% → 4–17%，7 个叠加 Bug，受影响用户 token 消耗 ×15）；智谱 GLM-5 缓存竞态（复读/乱码，约 5% 请求受影响，从异常到用户报告平均延迟 2.3h）
商业激励悖论	DeepSeek 缓存命中输入价 0.2 元 vs 未命中 2 元/百万 tokens（10 倍差）；“污染税”测算约 235 美元/月 vs 缓存节省约 30 美元/月（作者访谈估算）
替代方案：符号激活体系	本地密码本（符号索引）+ 轻量意图路由（0.5–2B）+ 云端解包路由，宣称压缩比 >95% 且噪声物理隔离；提供与 MCP 的衔接方案（symbol:// 资源类型等）

表 8-2 · 《记忆的困境》核心论点速览，注意：以上均为作者自述实验/案例分析，尚未经独立同行评审，引用时保持批判距离

本喵怎么看：不管符号激活体系最终能否落地，“把静态知识外置、动态请求独立、噪声物理隔离”的方向，和 Anthropic 上下文工程四件套、Letta 的分层记忆、Mnemosyne 的档号制在精神上是同一条路，记忆层的价值不在“记住多少”，而在“复用多少、污染多少”。这正是“记忆工程 = 驾驭工程”的最佳注脚。

8.4 一个完整的研究体系：Agent OS → Goldshine → 记忆宫殿 OS

把主理人的这几件公开研究串起来看（均标注自述性质），它其实是一条从“单节点”到“网络”再到“记忆底座”的完整路线：

AgentOS（my.g-cat.cn/experience/agent-os.html，GCAT/0101，V3.1），“注册表、编译器与云内存”：四表分离记忆、编译化工单协议（L1 规则 + L2 模型两级编译器）、云内存指针服务（cache_store / cache_load）。“指针优于数据、协议优于提示”，即单节点时代的“驾驭工程”。
Goldshine Protocol（§8.2），网络时代的“驾驭工程”：把单节点的 Agent 变成网络上可交付、可路由、可结算的能力节点（作者自述为“智能体操作系统”研究体系第二部分）。
记忆宫殿 OS（Mnemosyne-OS）（§6.2），记忆底座：给这套体系配“认知型记忆”，宫殿分类 + 档号 + 三通道召唤 + 热度衰减 + 端云同步。
《记忆的困境》（§8.3），理论层：论证为什么“记忆崇拜”该让位给“通信本位”，并给出符号激活体系作为重构方案。

⚠️ 客观口径：以上四项中，AgentOS / Goldshine / 记忆宫殿 OS /《记忆的困境》均为作者自述的设计、实验或经验分享，未被独立第三方工业验证或同行评审；Mnemosyne-OS 与 noah-gen3-type2 是真实存在的公开仓库（MIT），可自行审计。这里把它们作为“自研协议层/记忆层”的真实案例引用，不背书其宣称的性能与安全数据。

8.5 趋势判断（本喵的结论）

① 内核越强，基础外设越薄

指令遵循、长上下文、官方 memory、结构化输出持续内化，2023 年的“Prompt 玄学”正在变成模型默认能力。别囤外设对抗内核进化。

② 但“控质量、控成本、控安全”只会更重

上下文腐烂、提示注入、成本失控、可观测缺失，这些是内核进化解决不了的，它们正是驾驭工程永远存在的理由。

③ 协议层是下一个战场

MCP（工具）、A2A（Agent 互操作）、能力交付网络（自研方向）会并存分化；谁定义了标准契约，谁就拥有“强耦合点”的主导权（§3 说过：契约即权力）。

④ 记忆会从“存储”走向“生命周期”

写入、蒸馏、衰减、遗忘、复现，Mnemosyne 宫殿 OS 已经跑在这条路上，官方 memory 也在跟进。忘得聪明的 Agent 比记得多的 Agent 更可靠。

⑤ “一段代码调 API”永远成立

无论协议多花哨、记忆多聪明、编排多复杂，它们最终都汇入同一次 API 调用。内核没变，变的只是我们如何驾驭它。

✓附：10 问自查表

发稿前本喵拿这 10 个问题把自己这套系统过了一遍。你也可以花两分钟过一遍，答不上来的那一问，通常就是对应该补的那个赛道。

你的内核跑得通吗？能不能只用一段代码调通 API、拿到一次正确回复？（不行就别往下看了）
换模型要改几行？改一行配置就够，还是要动调用代码？（答案越接近"一行"越好）
外设装得上、也拆得掉吗？随手删一个组件，系统还能跑吗？
同一件事做过一遍，第二遍还教吗？（这就是 Skill 要解决的问题）
你的上下文是"拼"出来的还是"攒"出来的？每一轮都知道自己塞了什么吗？
记忆有没有清理机制？只写不删的记忆，半年后就是噪声矿。
有回归基线吗？改完 prompt 或工具，能不能一条命令验出"没变笨"？
危险动作有闸门吗？有写权限和联网的 Agent，一次误操作就是真实损失。
出问题看得见吗？是能看到日志，还是只能看到"今天好像不太对"？
账单能对上人话吗？这个月花的钱，能不能说清是哪几个组件花的？

图 A-1 · 能装上的零件，也要能好好收回去，这就是「可插拔」最实在的样子

十问对应十个赛道：④ 工具 · ⑧ 网关 · ③⑥ 记忆与技能 · ②⑨ 上下文与运行时 · ⑩ 评估 · ⑫ 安全 · ⑧ 成本。

9参考文献与来源清单

全文所有关键论断的来源，按类别排列，均可点击。版本与数据以 2026-09 检索实况为准；标注“社区说法”“作者自述”的条目请自行核对原文。

官方文档 / 官方站

DeepSeek Harness 官方站（Everything is a Plugin / Cordis 内核）— github.com/deepseek-ai/deepseek-harness
deepseek-ai/deepseek-harness（GitHub 仓库，docs/architecture.md、docs/cordis-primer.md）— github.com/deepseek-ai/deepseek-harness
NousResearch/hermes-agent（GitHub README：learning loop、skills、subagent、execute_code、Native Windows 安装）— github.com/NousResearch/hermes-agent
Hermes 官方文档（Architecture / Skills / Plugins / Memory / MCP / Context Compression）— hermes-agent.nousresearch.com/docs
Hermes 插件三发现源与 context API（~/.hermes/plugins、项目级、pip entry points）— hermes-agent.nousresearch.com/docs/developer-guide/architecture
Hermes Skills 系统（agentskills.io 兼容、tap add / install、learning loop）— hermes-agent.nousresearch.com/docs/user-guide/features/skills
Hermes Memory Provider 插件指南 — docs/developer-guide/memory-provider-plugin
Hermes Context Engine 插件指南 — docs/developer-guide/context-engine-plugin
Hermes 上下文压缩与缓存（双压缩：Agent 默认 50% 阈值 + Gateway 85% 安全网；Context Engine 可插拔）— docs/developer-guide/context-compression-and-caching
MCP 官方 spec（transport、client-host-server）— modelcontextprotocol.io
MCP 官方 Registry — registry.modelcontextprotocol.io
agentskills.io 开放标准（SKILL.md 规范）— agentskills.io/specification.md
Anthropic《Effective context engineering for AI agents》（context rot、compaction、note-taking、sub-agent、JIT 检索）— anthropic.com/engineering/effective-context-engineering-for-ai-agents
Anthropic《Writing effective tools for agents》— anthropic.com/engineering/writing-tools-for-agents
Anthropic Agent Skills（标准发源地）— docs.claude.com/.../agent-skills/overview
Claude Code 权限模式与沙箱 — code.claude.com/docs/en/permission-modes
Anthropic Memory 发布（2025-09/10）— anthropic.com/news/memory
OpenAI Function Calling 文档 — platform.openai.com/docs/guides/function-calling
OpenAI Agents SDK — openai.github.io/openai-agents-python
OpenAI ChatGPT Memory FAQ — help.openai.com/en/articles/8590148-memory-faq
LangChain《Workflows and agents》（workflow vs agent 官方定义）— docs.langchain.com/oss/python/langgraph/workflows-agents
LangGraph Checkpointer（thread_id / time-travel / interrupt）— docs.langchain.com/oss/python/langgraph/checkpointers
OWASP Top 10 for LLM Applications 2025（LLM01 提示注入）— genai.owasp.org/llmrisk/llm01-prompt-injection
LiteLLM Proxy 文档 — docs.litellm.ai
OpenRouter — openrouter.ai
Qdrant 官方混合检索指南（dense + sparse + RRF）— qdrant.tech/blog/hitchhikers-guide
llama.cpp（GGUF 量化）— github.com/ggerganov/llama.cpp
Ollama（内置 OpenAI 兼容 /v1）— ollama.com
vLLM 文档（PagedAttention）— docs.vllm.ai
Mem0 — github.com/mem0ai/mem0
Letta（原 MemGPT）— letta.com
GPTCache（语义缓存）— github.com/zilliztech/GPTCache
promptfoo（evals CLI）— promptfoo.dev
DeepEval — deepeval.com
LangSmith 文档 — docs.langchain.com/langsmith/trace-with-opentelemetry

论文 / 学术

Mixture-of-Agents（MoA），Together AI — arXiv:2406.04692
GEPA（Genetic-Pareto Prompt Evolution）— github.com/gepa-ai/gepa（arXiv:2507.19457）
Cordis 论文《A Programming Paradigm for Spatiotemporal Composability》（preprint，北京大学 × DeepSeek-AI Harness 团队，2026-08-13 草稿）— 经 EggStriker.AI 拆解引用

社区深度拆解（DSH 等）

Fodev JEO《DeepSeek Harness: What If the Agent Loop Itself Were Just Another Plugin?》（2026-08-15）— akillness.github.io/posts/deepseek-harness-everything-is-a-plugin
EggStriker.AI《DeepSeek Harness Architecture Deep Dive: Cordis's Revertible Effects…》（2026-08-14）— eggstriker.com/en/blog/deepseek-harness-cordis-architecture-2026
EggStriker.AI《DeepSeek Harness Deep Dive: DeepSeek's Agent Is Here…》（2026-08-14）— eggstriker.com/en/blog/deepseek-agent-analysis-2026
AgentConn《Inside DeepSeek Harness: A Kernel, Not a Rival》（0.1.1-rc.2 源码拆解，dsh-base 78 条插件行；本机 0.1.7-rc.2 实测 93 条，2026-08-23）— agentconn.com/blog/deepseek-harness-plugin-architecture
OrcaRouter《DeepSeek Harness Plugins, Explained》（Standard/PTC/Minimal 模式）— orcarouter.ai/blog/deepseek-harness-plugins
Andrew.ooo《DeepSeek Harness Review: Everything Is a Plugin》(profile/bundle 分层) — andrew.ooo/posts/deepseek-harness-everything-is-a-plugin-review
DEV Community《DeepSeek Harness: What Happens When the Agent Runtime Becomes the Product》— dev.to/…
Production RAG in 2026（hybrid + RRF + context caching）— dev.to（社区说法）

用户自研项目与论文（均标注自述性质，可独立审计）

Mnemosyne-OS「记忆宫殿 OS」v8.0.0（仓库 VERSION 实况；README 的 release 列表最新条目仍停在 v7.8.4；宫殿分类、档号、三通道召唤、保留层级、注入调度器、MCP bridge、WIKI KB、端云同步；白皮书 v5.2 已过时，以仓库为准）— github.com/gymaira1990-jpg/Mnemosyne-OS
noah-gen3-type2「诺亚三代·二型」通用 AI 认知架构（上下文管理 38.5:1 压缩、六模块、MIT）— github.com/gymaira1990-jpg/noah-gen3-type2
GCat/0101《记忆的困境：大模型KV缓存机制引发的“上下文腐烂”现象及其系统性重构》（上下文腐烂/CRI/符号激活体系；作者自述实验，非同行评审）— my.g-cat.cn/experience/memory-dilemma.html（DOI 10.5281/zenodo.20433184）
Goldshine Protocol（金铲铲协议）v1.5.2：去中心化全局能力交付网络（ASU 五元组 / 6 扩展字段 / 双层注册 / 三级成本分级；作者自述设计白皮书，CC BY-SA 4.0）— my.g-cat.cn/experience/goldshine-protocol.html（论文 DOI 10.5281/zenodo.20789868）
A2A 分布式轻量落地（L1 发起 / L2 调度 / L3 执行，仅改 base_url；作者自述，仅限技术交流与研究）— my.g-cat.cn/experience/a2a-distributed-network.html
AgentOS（注册表 / 编译器 / 云内存；GCAT/0101，V3.1）— my.g-cat.cn/experience/agent-os.html

📌 引用纪律：DSH 的引文一律以官方仓库 github.com/deepseek-ai/deepseek-harness 的 docs/ 为准（底稿引用的 github.com/deepseek-ai/deepseek-harness 域名实测无法访问，已全部替换）；另，这篇区分了三种可信度，【官方文档事实】（可放心引用）、【社区拆解/说法】（可参考，已尽量多源交叉）、【作者自述】（真实存在但未独立验证，仅作案例展示）。任何数字请回原文核对。

来源与核对：官方口径以 2026-09-30 核对为准（DSH 官方仓库 docs/、Hermes 官方文档、MCP spec 2026-07-28、 agentskills.io 规范、OpenAI / Anthropic / LangChain / OWASP 官方文档）；Mnemosyne-OS 与 noah-gen3-type2 为可独立审计的公开仓库（MIT）。文中标注「作者自述」的案例与数据未做独立复现，引用时请保持批判距离。

token 实测口径：本机 state.db 记录、最近 30 个会话取中位数（115 次 API 调用 / 输入 18 万 token / 人打的字 422 字符）｜统计脚本随稿归档，可复算｜配图：小小橘（2D 日漫风，本喵自绘）｜文 / 小小橘 · 2026.09.30 ｜全文约 40 分钟

延伸阅读：《记忆的困境》 · 《Mnemosyne 白皮书》 · 经验分享 · 全部条目