前言

两年前的我与两年后的我对 AI 的看法是完全不同的，两年前 AI 才刚刚起步，那时的 AI 还停留在 Chat 对话这种形式上，对个人的帮助不大，再往后就是掘金扣子，早期的 Cursor 等等，像早期的 Cursor 个人也断断续续使用过几次，间隔几个月然后用上一次，得出的结论是有帮助，但更多用于源码阅读等自我学习的方向上，较少用于干活。

再往后，各种大模型争相露头，生态好像堆积了一堆想法一样，各种功能层出不穷，MCP 协议、Google 的 Agents 白皮书、AI 编辑器(Cursor、Windsurf、Copilot、Codex、Devin、Amplify)、Agent 工具(OpenClaw、Hermes Agent、Claude Code)、A2A 协议、一人公司概念与衍生出来的编排工具，等等这些。

到了今天，AI & Agent 生态已经非常完善，完全可以用来干活，进入生产力的阶段，所以在 2026 年的 6 月份开始，为了避免被时代抛弃，我开始尝试深度使用 AI Agent，并逐步搭建属于自己的工作流，这篇文章就是我对 AI Agent 使用的探索历程。

初始接触

一开始的想法比较简单，想的是通过 VSCode 插件 Cline 搭配 DeepSeek 去重构一个公司的老项目，在重构过程中深入理解 Agent 的使用场景与技能，选择 DeepSeek 的原因也很简单，国内友好易接触，便宜，加上之前 DeepSeek 在大众视线中经常出现。

计划赶不上变化，那时强迫症有点严重，没什么事就折腾一下自己的电脑，一些开发缓存、应用卸载残留什么的看不顺眼，就想着用 Agent 去排查清理，这是我第一次接触 Hermes Agent，这个阶段只是用 Agent 进行一些系统排查，或者是简单想法的规划、帮跑本地模型等等，还没有到编码干活的阶段。

这时候对大模型 & Agent 的理解还不深刻，对他们的能力、使用边界等都没有清晰的认知，因为还没有深入使用，大模型 & Agent 的能力、短板都没有暴露出来。

开发自用 Utility 软件

我常用的软件就是翻译、拖拽暂存、剪切板管理，这些小功能其实一个软件就可以搞定，但我能找到的都是一个小功能作为一个软件，虽然轻量，但我希望能将他们整合为一个软件同时保持轻量，于是我开始用 Agent 来开发自用的 Utility 软件，使用原生 Swift，全程只做需求规划、审查计划、审查代码等事情，编码完全交给 Agent 取做。

开发流程就是：输入需求规划->Agent 输出计划->审查、改动计划->Agent 实现->人工审查。

看似简单，但确实暴露了很多问题：

1. 长上下文丢失：在连续对话过程中，上下文被污染，一些重要的上下文在经过多轮对话后，大模型已不再遵守
2. 强缓存：更相信记忆而不是实际内容，在手动修改内容后，后续修改 Agent 依然使用记忆内容覆盖本地实际内容
3. 跨会话理解缺失：上一个会话写的代码，下一个会话不理解，并将满足业务的正常代码修改为不可正常使用的代码
4. 全局掌控力丢失：长上下文时，只关注局部代码，不看从全局视野出发；完成一个功能后，完成另一个有相同内容的需求，只从当前需求
   出发规划，不从全局出发考虑封装
5. 极度自信：在编码时，更相信根据训练数据生成的内容，不考虑实际，在针对 bug 场景时，经常出现多轮对话后，仍在靠猜测修改代码，不考虑实际调试
6. 文本模型的专属问题：DeepSeek 没有多模态能力，针对 UI 设计、调整的需求，经常要多轮详细描述后才能达到一个较为满意的结果

Coding Agent 与 Claude Code 的使用

针对上述问题，我与 Hermes Agent 进行了对话，询问通用 Agent 与 Coding Agent 的区别，在上述 1、2、3、4 问题上，为什么 通用 Agent 与 Cursor/Coding Agent 这类工具的表现差异很大，是否因为 Cursor 索引了代码库，实现了向量嵌入。

Hermes Agent 给出的结果是四层差异架构：

差距是一个四层技术栈，只有一层是向量数据库： - Layer 1: 代码检索层（Code Retrieval） - 嵌入向量语义搜索 ← 向量数据库 - AST 解析 → 符号索引 - BM25 词法搜索（grep 增强版） - 调用链/依赖图遍历 - Layer 2: 项目记忆层（Project Memory） - 自动从代码结构推导架构理解 - 增量更新（只重新索引变更的文件） - 跨会话持久化 - Layer 3: 上下文编排层（Context Orchestration） - 分层优先级（规范 > 当前代码 > 历史 > 工具输出） - 动态检索（根据当前任务拉取相关代码段） - 编辑前强制校验（read-before-write guard） - Layer 4: 编辑基元层（Edit Primitives） - 结构化 diff 应用（不是全文 write_file） - 多文件协同编辑（一次生成多个相关文件的改动） - 语法感知的 patch（不会破坏语法结构）

于是我尝试使用 Claude Code 进行开发，但除了编码能力有一定提升、模型上下文满了会自动压缩外，其他没有明显的改善，该有的问题一样有，看起来这些 CLI Agent 都拥有这种通病，因为他们不会进行代码库的向量索引，我们还无法完全发挥 AI Agent 的潜力。

MCP 协议与共享记忆体的使用

时间线再往后推，基于下列多种原因，我决定开发一个 MCP 共享记忆体，用于满足需要：

• 在与 Agent 输出自己的想法时，在对话过程中，经常会诞生一些有价值的信息，这些信息只存在于对话记忆中，或是特定 Agent 的持久化文件中，只要 Agent 被卸载，这些内容也会丢失
• Hermes Agent、Claude Code 双持，他们没有一个统一的数据来源，各种资源(System Prompt、Skill、Tool 等)都存放在不同 Agent 的本地文件中
• 我需要一个共享记忆层

MCP 共享记忆层/知识库的设计：

• 记忆/知识库包含热层、冷层

  • 热层：数据库层，存放较热的数据
  • 冷层：用户笔记层，存储为 markdown 文件，存放有价值的归档数据，用于持久化，用户可读，MCP 可消费

• 暴露多种关键工具

  • 写入记忆工具
  • 搜索记忆/知识库工具，支持向量搜索
  • 获取最近记忆/知识库的工具

• 记忆归档总结：设计一个定时任务，针对最近三天的记忆进行提炼总结，生成有价值的文章沉淀到冷层

• 数据热度排序：访问的记忆加分，长期未访问的记忆减分，热度较低的数据更容易被归档删除

形成一套自循环的系统，消费记忆/知识库->写入记忆/知识库->沉淀记忆/知识库->消费记忆/知识库。

这套系统的基础设计如此，但更重要的是如何使用，在实际测试中，大模型调用这套 MCP 工具的意愿极低，因为我陷入了一个误区，认为大模型是一个具有高度智慧的严格遵守提示词的 “人”，我是这样使用他的：

• 完全通过对话、提示词来指示大模型干活
• 在一些 tools 的返回文本中添加强化提示词，比如让大模型执行某个 tools 后，末尾再次加上这个 tools 的触发条件，意欲强化大模型调用这个 tools 的意愿
• 在提示词中，强制大模型遵守某种特定的规则，比如让大模型每次对话后执行某个操作
• 提示词使用模糊的描述

这就是没理解大模型 & Agent 的能力边界，大模型针对提示词一般都有缓存，多次相同的文本输入，更可能是直接命中缓存，而达不到强化的目的，同时大模型在多轮对话后，上下文被污染，固定调用某个 tools 的可能性变得更低，而且大模型更喜欢命令明确、步骤式的指令。

同时：提示词原则——负向约束比正向要求更有效。明确规定 “禁止做什么”。例如要求 “操作文件前先走完 MCP 工具、记忆搜索、本地搜索三层检索链路” -> “禁止在未走完三层链路前操作文件”，实测比正向描述更能稳定约束大模型的行为。

实际使用大模型时，需要考虑在什么时候使用什么能力：

• System Prompts: 一些重要的事实，比如规范等描述类内容
• Rules: 命中某种模式时应用的规则
• Skills: 一些复杂逻辑，基本固定的流程
• Tools: 提供某种能力、工具

针对到我的场景又不一样，在现有 MCP 协议中，并没有支持远程 Skills、System Prompts(主动加载式、关键词触发式)、Rules 的支持，于是我退而求其次，将 tools 能力作为 Skills、System Prompts 使用，MCP 的 tools 支持 description 描述字段，大模型通过这个字段来决定是否调用。

一个好的描述应该是有明确的触发条件的，不只是说明功能，还要说明什么时候应该被调用，比如：

当用户说：日报、今日日报、今日完成任务、今天工作结束; 等工作总结类内容时调用。用于从 MCP 共享记忆、会话记忆、Git 提交记录和未提交变更中收集信息，生成面向功能的每日工作报告。

会比：

用于从 MCP 共享记忆、会话记忆、Git 提交记录和未提交变更中收集信息，生成面向功能的每日工作报告。

更容易被大模型触发调用，我只需要在每天工作完成时，对他说 “日报” 即可。

这套系统初期还没有显现威力，但在后续不断的完善，记忆追加的过程中，已经成为工作流中不可或缺的一部分，虽然在后续放弃了 Hermes Agent，只用 Claude Code，“共享” 记忆层的作用名存实亡，但记忆层仍能够帮助 Agent 在跨会话开发的时候了解项目。

Utility 整合与依赖图扫描

在之前的问题描述中，一些内容已被解决：

1. 长上下文丢失：Claude Code 在上下文满时会自动压缩上下文，加上记忆层，再使用指令式描述，能够缓解一定的上下文丢失问题
2. 强缓存：Claude Code 在编辑文件失败后，会主动读最新文件，以实际内容为主
3. 跨会话理解缺失：MCP 记忆体较大的改善了这个情况
4. 极度自信：优化系统提示词，要求基于事实而不是猜测，同时添加 skills，用于排查步骤

还有一个有待解决的问题是全局代码掌控能力，我需要一个针对特定代码库的依赖图，用于增强 Agent 的全局视野。

设计方案是这样的：Utility 作为一个自用工具，支持自定义扩展，我希望实现一个 utility cli 模式，使用方式：

utility-a"agent cmd"# eg: utility -a claude

设计理念：

• 创建一个 utility cli 进程
• 扫描器扫描项目依赖图
• 生成依赖图数据库存放在项目的 .utility 目录下
• 同时侦听文件变化，更新依赖图
• MCP 暴露一个工具，接受项目路径，当触发时，连接搜索指定的项目依赖图数据库

这样，当特定工具被调用时，根据符号检索数据库，获取到对应的代码路径等可用内容。

之前 MCP 是单独一个 python 项目，运行在 Docker 中，利用这个机会，将 MCP 项目集成至 Utility 项目中，由 Utility 项目统一管理，还可以去掉 Docker 这个很重的运行时。

Orchestrate 编排

在实际体验中，Agent 经过多轮对话，依然会有降智的表现，如果新开一个会话就能够改善。于是我诞生了一个实现一个编排器的想法，设计理念：

• Utility 实现一个 loop 循环编排器
• 输入计划
• 启动多个子 Agent 进程
  • Coding Agent: 负责编码，拥有持久化上下文
  • Reviewer Agent: 负责审核，永远是干净的上下文，只负责审查与建议，实际是否接受由 Coding Agent 进程
• 不断循环，直至计划被完成

我的想法是通过一个干净的 Agent，查看可能被 Coding Agent 忽视的代码逻辑漏洞、架构等，用于提示 Coding Agent。

这个功能实现并验证过，但后续代码被移除，没有在日常工作流中持续使用，不过沿这个思路一直优化下去是有用武之地的。

工具调用统计

在使用过程中，只是知道 Agent 调用了一些工具，调用了哪些工具、调用了几次是完全不知道的，当工具多起来的时候，哪些工具被经常调用，哪些工具调用的少或完全不调用，是完全不知道的，这会导致一些工具长时间的被忽视、搁置。

针对这个情况，在 MCP 服务层做了埋点，统计每天的工具调用次数，哪些工具调用的多，哪些工具调用耗时长，哪些工具是冗余。

然后可以根据这些数据，再明确一个优化方向，哪些工具描述要优化，哪些工具的性能要排查，哪些工具可以被删除等等。

Token 调用统计

与工具调用统计是一个道理，但更重要，可以记录 token 使用量、api 请求次数、缓存率等等，我曾经在某天使用了 DeepSeek-v4-Pro 60 块钱，之前的消耗大多在 10-20 块左右，这次的异常后续排查原因归结为缓存率下降，所以这个埋点监控是很有必要的，能够让我们访问 “黑洞” 系统。

实现要点：

• 创建一个 API 代理服务
• 记录响应中的各种字段，包含输入 token、输出 token、缓存 token 等
• Agent 改为访问代理服务

由于使用了代理，我们还能实现其他功能，比如之前说的输入缓存问题，因为 Agent 在请求时针对一些提示词设置了缓存参数，我们可以在请求到来时，针对重要的系统提示词去除缓存参数，还可以实现动态内容注入，实现配置化。

Lody 编排

针对工作流，希望实现一个微信对话式的需求列表、面板，核心功能：拉取需求->创建子会话->设计->反馈确认->Coding Loop(开发->询问->自验)->反馈确认->最终完成

问了我的小伙伴，推荐 Lody 工具，只需要两个 Skills 与提供配置即可：

• 需求拉取 Skills：通过配置从需求源拉取多条需求，同步创建 Lody 子会话，子会话初始规划需求
• 规划、流程 Skills: 初始调研、规划需求，当用户确认后进行状态的流传

如果只是单纯这套设计，使用起来肯定会被阻塞住，搭配 MCP 记忆层就可以很好的感知项目上下文，甚至是跨项目感知上下文。

这套设计最终落地时，沉淀为 devflow 研发编排 + 云效（Yunxiao）MCP：云效 MCP 负责从需求源拉取需求、创建变更、流转工作项状态、在代码评审上评论；配套的 Skills 负责接收需求、初始调研与规划，用户确认后进入开发循环——建需求分支、调研、设计方案、反馈确认、开发与测试、最终验证，再回到云效做状态流转与汇报。主控逻辑以 Skill + MCP 工具的形式独立存放、跨项目复用，让「拉需求→开发→验证→回报」整条链路在 Agent 的辅助下跑起来。