【Agent Harness】Gliding Horse 高级认知优化：让 Agent 的“大脑”和“免疫系统”真正协同
Gliding Horse 高级认知优化：让 Agent 的“大脑”和“免疫系统”真正协同
摘要：本文深入解析 Gliding Horse 高级认知优化，聚焦 Agent 的“大脑”（SA 调度、技能图谱）与“免疫系统”（安全门禁）如何真正协同。涵盖动态 PDCA 编排、四层记忆、技能图谱自进化、因果引擎、Hyperspace 向量检索等核心模块的集成优化，以及安全执行策略的精准升级。适合对 Agent 操作系统、Rust 系统工程、知识图谱与因果推理感兴趣的开发者。
关键词：Gliding Horse；Agent 操作系统；认知优化；技能图谱；安全门禁；因果引擎；向量检索；Rust
Gliding Horse 从一开始就构建了一套完整的智能体系：动态 PDCA 编排、四层记忆、技能图谱自进化、因果引擎、Hyperspace 向量检索……这些模块在之前的文章中都有详细介绍。
但一个系统不仅要“有”这些能力，更要让它们在实际运行中真正协同起来。如果技能图谱记录的执行反馈和 Agent 实际运行使用的是两套数据，如果安全门禁在保护系统的同时也误伤了自己人，那再好的模块也只是“存在”而已。
这次优化要解决的核心问题正是这个：把各个高级模块之间的“接线”真正接通，把安全机制打磨得更智能。
一、优化后的整体架构
这次优化的核心主线是：任务终结 → 技能反馈 → 知识图 → 技能图 → 向量恢复 → 快照 → 演化 proposal → 安全执行。这条链路上的每一个环节都经过了验证和加固。
二、高级认知主链：让反馈真正回流
Gliding Horse 的技能图谱从来不是静态的——它记录技能的使用频率、成功率、依赖关系，并能根据这些数据自动生成演化建议。但之前有一个问题：不同执行入口（CLI、TUI、resume）的任务终结处理是分叉的，导致某些路径的技能反馈没有正确写入图谱。
这次修复让三个入口共享统一的 TaskFinalizer，确保无论通过哪种方式执行任务，任务状态、因果观察、经验记录和时间线快照都能完整写入。ToolExecutor 的知识图谱引用也被统一，不再出现“Agent 跑完了但技能使用记录写到旧图谱”的问题。
下面是一个简化的 Rust 代码示例，展示如何创建和使用共享的 TaskFinalizer，确保技能反馈正确写入图谱：
use std::sync::Arc;
use tokio::sync::Mutex;
/// 共享的任务终结器，统一处理所有执行入口的反馈写入
pub struct TaskFinalizer {
skill_graph: Arc<Mutex<SkillGraphStore>>,
knowledge_graph: Arc<Mutex<UnifiedKnowledgeGraph>>,
timeline: Arc<Mutex<TimelineStore>>,
}
impl TaskFinalizer {
/// 创建共享的 TaskFinalizer 实例
pub fn new(
skill_graph: Arc<Mutex<SkillGraphStore>>,
knowledge_graph: Arc<Mutex<UnifiedKnowledgeGraph>>,
timeline: Arc<Mutex<TimelineStore>>,
) -> Self {
Self { skill_graph, knowledge_graph, timeline }
}
/// 终结任务并写入所有反馈数据
pub async fn finalize(&self, task: &TaskResult) -> Result<(), FinalizeError> {
// 1. 记录技能使用情况（频率、成功率、依赖关系）
let mut sg = self.skill_graph.lock().await;
sg.record_usage(&task.skill_invocations).await?;
// 2. 写入因果观察（任务状态、决策路径）
let mut kg = self.knowledge_graph.lock().await;
kg.record_causal_observation(&task.causal_chain).await?;
// 3. 创建时间线快照（用于后续回滚和审计）
let mut tl = self.timeline.lock().await;
tl.create_snapshot(&task.snapshot_data).await?;
Ok(())
}
}
// 使用示例：CLI 入口和 TUI 入口共享同一个 TaskFinalizer
#[tokio::main]
async fn main() {
let finalizer = Arc::new(TaskFinalizer::new(
Arc::new(Mutex::new(SkillGraphStore::new())),
Arc::new(Mutex::new(UnifiedKnowledgeGraph::new())),
Arc::new(Mutex::new(TimelineStore::new())),
));
// CLI 入口
let cli_finalizer = finalizer.clone();
tokio::spawn(async move {
let task = run_cli_task().await;
cli_finalizer.finalize(&task).await.unwrap();
});
// TUI 入口
let tui_finalizer = finalizer.clone();
tokio::spawn(async move {
let task = run_tui_task().await;
tui_finalizer.finalize(&task).await.unwrap();
});
}
通过 Arc 和 Mutex 共享同一个 TaskFinalizer 实例，CLI、TUI 和 resume 三种入口都能将任务状态、因果观察、经验记录和时间线快照写入同一套存储，确保技能反馈不会丢失或分叉。
动态技能创建现在有了完整的补偿 saga：如果创建过程中途失败（比如索引写入成功但向量存储失败），系统会自动回滚已完成的部分，不会留下半完成的技能定义。同时，定义型技能被显式标记为 definition_only，不会错误地出现在可执行候选中。
演化提案系统也做了扩展。之前只支持 AddLink（建议添加新的技能关联），现在同时支持 RemoveLink（建议移除过时或有害的关联）。所有提案都经过人工审批、基线版本校验、安全策略检查和图结构验证，审批通过后才写入技能图谱，启动时自动恢复。
三、数据恢复能力增强
在长时间运行后，系统需要能从持久化存储中完整恢复。这次优化补齐了几个关键的数据恢复路径：
- L0 完整节点恢复：所有技能图谱节点都能从 L0 持久层完整重建，包括时间戳、状态标记和链接关系。
- Timeline 完整快照：时间线存储支持完整的快照创建和 mutation replay，回滚时不仅恢复节点数据，还会补偿 skill、hyperedge、MOC 和知识碎片。
- Hyperspace 向量恢复：修复了 WAL（预写日志）的 checkpoint 和 reopen 流程，确保向量存储重启后数据一致；修复了 filter 三态问题、upsert/delete 的元数据和 HNSW 索引一致性问题。
递归 AST 扫描现在覆盖了 CLI、TUI 和 resume 三种执行模式，支持固定排除规则、配置排除规则和 .gitignore 子集，让代码结构提取更精准。
四、安全执行：在保护和可用之间找到平衡
Gliding Horse 的安全门禁（SecurityEngine）一直执行 fail-closed 原则——不认识的工具一律拒绝。这本身是正确的安全策略，但在实际工程任务中遇到了一个具体问题：file_write 和 bash 这类系统内置技能，在某些配置下被默认风险策略拒绝，导致正常的工程任务无法完成。
另一个问题是，executor 的内置工具和派生结果读取工具没有独立的 Registry skill，在执行安全决策时被判定为“未知工具”而拒绝。
这次优化没有放松安全策略，而是让它更精准：
核心改进在于 显式能力映射：系统启动时从 SkillGraph 加载 SystemBuiltin 基线技能作为可信白名单；对于 tool_search、文件读取等内置工具，映射到 file_read 能力；对于 bash、文件写入等工具，映射到 file_write 能力；网络工具映射到 http_request；结果读取工具映射到只读能力。用户定义的技能和真正的未知工具仍然会被拒绝。
这样，安全门禁在保持 fail-closed 原则的同时，不再误伤系统正常运行所需的必要工具。
五、可验证的提升
| 维度 | 优化前 | 优化后 |
|---|---|---|
| 入口一致性 | CLI/TUI/resume 后处理分叉 | 三入口共享终结、反馈、代码图与向量准备链 |
| 数据恢复 | 部分恢复路径有语义丢失风险 | L0 完整节点、Timeline 快照、Hyperspace WAL/reopen 全链路验证 |
| 工具安全 | 主循环可能绕过 executor policy | 统一 executor 路径，SecurityEngine 强制决策与审计 |
| 动态技能 | 可能半注册或被误标为可执行 | 补偿 saga、definition-only 隔离、真实 handler 前不进候选 |
| 演化变更 | 非持久建议或仅 AddLink | durable AddLink/RemoveLink proposal、审批与恢复 |
| 真实任务适配 | 内置/派生工具被安全机制误拒 | 显式最小能力映射，未知工具仍 fail-closed |
验证数据：核心库 1177 个测试通过，Hyperspace 引擎 102 个测试通过，真实任务复现确认之前的误拒绝问题已修复。
六、这次优化的本质
如果把 Gliding Horse 比作一个生物体，那么之前它已经拥有了完整的大脑（SA 调度）、记忆系统（L0-L3）、技能网络（SkillGraph）和免疫系统（SecurityEngine）。这次优化做的不是“移植新器官”，而是打通神经系统——让大脑能准确读取记忆，让免疫系统在保护身体的同时不误伤正常细胞，让每一次行动都留下可追溯的反馈。
这些改进让 Gliding Horse 从“各模块都能独立工作”的阶段，迈入了“模块间真正协同”的新阶段。它不再只是一个功能齐全的工具箱，而是一台各个齿轮紧密咬合的机器。
七、写在最后
Gliding Horse 从第一天起就在回答一个问题：如何让 AI Agent 从“聪明但散漫”变成“可靠且可依赖”。
每一次迭代都在让这个答案更完整。如果你对 Agent 操作系统、Rust 系统工程、或者知识图谱与因果推理的结合感兴趣，欢迎来 GitHub 看看：
👉 https://github.com/doiito/gliding_horse
项目还在快速迭代中，文档和示例正在持续补全。如果你愿意一起探索 Agent OS 的边界，star 和 issue 都是最好的支持。
浙公网安备 33010602011771号