/tags/mcp/ Recent content in MCP on 星澜 Hugo zh-CN Sun, 29 Mar 2026 13:00:00 +0800 /post/2026/03/29/2026032904/ Sun, 29 Mar 2026 13:00:00 +0800 /post/2026/03/29/2026032904/ <h2 id="引言">引言</h2> <p>前面两篇篇把概念、演进背景和验证设计铺开了，从这篇开始落地。</p> <p>《<a href="/post/2026/03/29/2026032901/">01. AI Agent 与 Harness：概念梳理</a>》里提到两类场景，这篇先讲第一类：对大多数团队来说，眼前更现实的任务并不是马上造一套业务 agent 系统，而是先把 <code>Codex</code>、<code>Claude Code</code> 这类现成 agent 用稳。</p> <p>这时候真正需要补的，就是团队自己的那层 harness——仓库里的这些东西：</p> <ul> <li>repo instructions</li> <li>skills</li> <li>MCP 使用约定</li> <li>验证命令</li> <li>交付格式</li> <li>review / CI workflow</li> </ul> <p>放到一个典型的后端团队里，这件事会变得很具体：</p> <ul> <li>Web 框架用 <code>gin</code></li> <li>数据层用 <code>gorm</code></li> <li>缓存用 <code>redis</code></li> <li>已经有链路追踪</li> <li>也能通过 MCP 查日志、查 traces、查数据库</li> </ul> <p>问题也会跟着收敛成一句话：</p> <p><code>在这种团队里，怎么把默认工作方式写成 agent 也能稳定遵守的仓库规则？</code></p> <h2 id="团队上下文要写清楚">团队上下文要写清楚</h2> <p>很多团队装了 MCP、写了几句提示词，就以为自己已经在做 harness。<br> 但如果 agent 连“这个仓库到底怎么工作”都不知道，它其实还是进不了团队的真实语境。</p> <p>所以第一步不是堆工具，而是把上下文写明白。</p> <p>像一个 <code>gin + gorm + redis</code> 的 Go 团队，至少要把这些共识显式化：</p> <ul> <li>项目目录结构</li> <li>HTTP 层怎么组织</li> <li>service / repository 怎么分层</li> <li><code>gorm</code> 查询和事务怎么写</li> <li><code>redis</code> key 命名、TTL 和失效策略怎么定</li> <li>trace 和日志字段怎么打</li> <li>什么命令算基本验证</li> <li>什么结果才算 done</li> </ul> <p>这些东西如果只存在于资深同事脑子里，agent 是用不稳的。</p> /post/2026/03/29/2026032901/ Sun, 29 Mar 2026 09:00:00 +0800 /post/2026/03/29/2026032901/ <h2 id="引言">引言</h2> <p>最近一直在反复想几个词：<code>agent</code>、<code>harness</code>、<code>skill</code>、<code>tool</code>、<code>MCP</code>、<code>context</code>、<code>memory</code>。<br> 它们在视频、推文、产品宣传、框架文档里经常被混着说，结果就是每个词都像懂了，又都不算真懂。</p> <p>这篇文章想做的事很简单：把这些词放回工程语境里，先理顺它们之间的关系，再把这组文章的阅读顺序摆清楚。</p> <h2 id="总结">总结</h2> <ul> <li><code>Model / LLM</code> 是底层推理与生成能力，不等于完整 agent</li> <li><code>Agent</code> 是带有目标、状态、工具使用和多步行动能力的 LLM 系统</li> <li><code>Harness</code> 不是某个单独组件，而是让 agent 稳定完成任务的整套工程化装置</li> <li><code>Skill</code>、<code>Tool</code>、<code>MCP</code> 往往都是 harness 的组成部分，但它们单独都不等于 harness</li> <li><code>Prompt engineering</code> 解决的是“怎么说”，<code>context engineering</code> 解决的是“让模型看到什么”，<code>harness engineering</code> 解决的是“怎么让整个系统稳地做完”</li> </ul> <p>压成一句话就是：</p> <p><code>model 负责想，agent 负责持续做，harness 负责让它做得稳、做得可控。</code></p> <h2 id="概念地图">概念地图</h2> <ul> <li><code>Model</code> <ul> <li>提供理解、推理、生成能力</li> </ul> </li> <li><code>Prompt</code> <ul> <li>决定你怎么和模型说话</li> </ul> </li> <li><code>Context</code> <ul> <li>决定当前这一轮让模型看见什么</li> </ul> </li> <li><code>Memory</code> <ul> <li>决定哪些经验和状态可以跨轮次复用</li> </ul> </li> <li><code>Tool</code> <ul> <li>决定 agent 能调用哪些外部能力</li> </ul> </li> <li><code>MCP</code> <ul> <li>决定外部系统如何以统一方式接进来</li> </ul> </li> <li><code>Skill</code> <ul> <li>决定一类任务该按什么方法做</li> </ul> </li> <li><code>Agent</code> <ul> <li>决定系统是否能围绕目标持续行动</li> </ul> </li> <li><code>Harness</code> <ul> <li>决定这个 agent 最终能不能稳定、可控、可交付</li> </ul> </li> </ul> <p>从工程视角，三者的包含关系更像：</p> <p><code>harness 包含 agent，agent 使用 model</code></p> <p>也就是：</p> <ul> <li><code>model</code> 是能力底座，是 agent 的推理内核</li> <li><code>agent</code> 是基于 model 搭起来的行动闭环：<code>model + state + tool use + planning + action loop</code></li> <li><code>harness</code> 是把整个 agent 包裹起来的工程装置：上下文、工具、权限、验证、返工、观测——都在里面</li> </ul> <h2 id="modelpromptcontextmemory-到底是什么关系">Model、Prompt、Context、Memory 到底是什么关系</h2> <p><code>Model</code> 比较像大脑。</p>