前言两年前的我与两年后的我对 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 实现-人工审查。看似简单但确实暴露了很多问题长上下文丢失在连续对话过程中上下文被污染一些重要的上下文在经过多轮对话后大模型已不再遵守强缓存更相信记忆而不是实际内容在手动修改内容后后续修改 Agent 依然使用记忆内容覆盖本地实际内容跨会话理解缺失上一个会话写的代码下一个会话不理解并将满足业务的正常代码修改为不可正常使用的代码全局掌控力丢失长上下文时只关注局部代码不看从全局视野出发完成一个功能后完成另一个有相同内容的需求只从当前需求出发规划不从全局出发考虑封装极度自信在编码时更相信根据训练数据生成的内容不考虑实际在针对 bug 场景时经常出现多轮对话后仍在靠猜测修改代码不考虑实际调试文本模型的专属问题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 整合与依赖图扫描在之前的问题描述中一些内容已被解决长上下文丢失Claude Code 在上下文满时会自动压缩上下文加上记忆层再使用指令式描述能够缓解一定的上下文丢失问题强缓存Claude Code 在编辑文件失败后会主动读最新文件以实际内容为主跨会话理解缺失MCP 记忆体较大的改善了这个情况极度自信优化系统提示词要求基于事实而不是猜测同时添加 skills用于排查步骤还有一个有待解决的问题是全局代码掌控能力我需要一个针对特定代码库的依赖图用于增强 Agent 的全局视野。设计方案是这样的Utility 作为一个自用工具支持自定义扩展我希望实现一个 utility cli 模式使用方式utility-aagent 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 研发编排 云效YunxiaoMCP云效 MCP 负责从需求源拉取需求、创建变更、流转工作项状态、在代码评审上评论配套的 Skills 负责接收需求、初始调研与规划用户确认后进入开发循环——建需求分支、调研、设计方案、反馈确认、开发与测试、最终验证再回到云效做状态流转与汇报。主控逻辑以 Skill MCP 工具的形式独立存放、跨项目复用让「拉需求→开发→验证→回报」整条链路在 Agent 的辅助下跑起来。