<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Vic's Blog</title>
        <link>https://ababy.cyou/</link>
        <description>复杂系统、数据库治理与 AI 增强交付</description>
        <lastBuildDate>Sun, 06 Sep 2026 07:08:57 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <image>
            <title>Vic's Blog</title>
            <url>https://ababy.cyou/avatar.png</url>
            <link>https://ababy.cyou/</link>
        </image>
        <copyright>CC BY-NC-SA 4.0 2026 © Vic Wang</copyright>
        <atom:link href="https://ababy.cyou/feed.xml" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[AI 工具怎么选：模型、Harness 与那个被你忽视的 agents.md]]></title>
            <link>https://ababy.cyou/posts/ai-tools</link>
            <guid>https://ababy.cyou/posts/ai-tools</guid>
            <pubDate>Sun, 06 Sep 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[AI 浪潮这么久了，我才开始写工具教程——因为工具越装越多，反而会拖累一切。聊聊模型怎么选、harness 座驾怎么挑、为什么我放弃 MCP，以及为什么维护好一个 agents.md 能解决 90% 的问题。]]></description>
            <content:encoded><![CDATA[<h2>为什么现在才开始写 AI 工具教程</h2>
<p>AI 浪潮已经翻涌了这么久，各种教程、测评、安装指南满天飞，我却一直没动笔。不是没东西可写，而是<strong>过去这段时间大家（包括我）都在摸着石头过河</strong>：</p>
<blockquote>
<p>看到这个工具不错，装！看到那个框架很酷，装！折腾了一圈下来，工具箱越来越满，真正交付的东西却没变多。</p>
</blockquote>
<p>工具的堆叠不会自动带来生产力，反而会拖累所有东西——token 花得更快、上下文更乱、任务更容易跑偏。所以这篇教程不想罗列「必装清单」，而是想讲清楚三个决策：<strong>选什么模型、选什么 harness 座驾、维护哪一份配置</strong>。想通这三件事，90% 的折腾都可以省掉。</p>
<h2>一、模型怎么选：GLM 和 GPT</h2>
<p>先说结论：日常主力我推荐 <strong>GLM（智谱）</strong> 和 <strong>GPT（OpenAI）</strong> 两条线。</p>
<table>
<thead>
<tr>
<th>模型</th>
<th>适合场景</th>
<th>一句话评价</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>GLM 系列</strong></td>
<td>编码主力、长任务</td>
<td>国内直连稳定，Coding Plan 性价比高，订阅活动也多</td>
</tr>
<tr>
<td><strong>GPT 系列</strong></td>
<td>复杂推理、通用兜底</td>
<td>综合能力强，适合作为第二引擎交叉验证</td>
</tr>
</tbody>
</table>
<p>几个务实建议：</p>
<ul>
<li><strong>订阅走官方渠道</strong>。模型账号的「代充」「共享」渠道水很深，轻则掉额度，重则泄漏你代码库里的敏感信息——对工程师来说，后者是不可接受的。</li>
<li><strong>一个主力 + 一个兜底</strong>就够了。模型的边际收益递减很快，与其集齐七八个模型，不如把一个模型的上下文管理、任务拆分玩明白。</li>
<li>活动价可以薅，但<strong>别让「薅活动」本身变成一个工程</strong>。</li>
</ul>
<h2>二、Harness 座驾怎么选：很美，但不适合所有人</h2>
<p>选完模型，下一步是选 harness（座驾）——也就是承载模型的 CLI / IDE 框架。ECC、Superpowers 这类增强方案确实很美：自动记忆、自动技能加载、一堆预设流程，看起来一装就起飞。</p>
<p>但我得泼一盆冷水：<strong>这些东西并不适合所有人，尤其不适合新手</strong>。三个真实缺点：</p>
<ol>
<li><strong>Token 消耗多</strong>。增强框架会往每次对话里塞大量系统提示、记忆、技能说明，你还没开始干活，上下文已经烧掉一大截。</li>
<li><strong>限制模型能力</strong>。过度的预设流程等于替模型「想好了」做事方式，模型自己的判断力反而发挥不出来。</li>
<li><strong>任务跑偏</strong>。自动化链条越长，单点错误的放大越严重——一个小指令被误解，整条流水线都会带着错误往前跑。</li>
</ol>
<p>新手正确的路径是：<strong>先用裸 harness 把基本功练扎实</strong>（怎么写提示、怎么拆任务、怎么审查输出），再按需加装增强。配置是你自己的，能力才是你自己的。</p>
<h2>三、为什么我放弃使用 MCP</h2>
<p>这是个反直觉的决定——MCP（Model Context Protocol）明明是 2025 年之后最热的生态，工具一个接一个接入。但我的实际体验是：<strong>MCP 的进程膨胀问题，正在悄悄吃掉你的机器</strong>。</p>
<p>看一个真实案例。后台同时挂着多个 AI CLI 会话（ZCode / claude / codex / omp / ChatGPT 桌面版），<strong>每个会话都会把全套 MCP 各起一份进程</strong>，实测副本数：</p>
<table>
<thead>
<tr>
<th>MCP 服务</th>
<th>副本数</th>
</tr>
</thead>
<tbody>
<tr>
<td>dbhub</td>
<td>×46</td>
</tr>
<tr>
<td>context7</td>
<td>×44</td>
</tr>
<tr>
<td>deepwiki</td>
<td>×37</td>
</tr>
<tr>
<td>codegraph</td>
<td>×31</td>
</tr>
<tr>
<td>filesystem</td>
<td>×10</td>
</tr>
</tbody>
</table>
<p>合计约 <strong>168 个 MCP 进程</strong>：</p>
<p><img src="https://img.ababy.cyou/images/2026/09/ai-tools/mcp-processes.png" alt="实测 MCP 进程数：约 168 个进程、6.5GB+ 内存"></p>
<p>对应 <code>node×96 + cmd×101 + npx×28</code>，每个实例 50~110MB，总计吃掉 <strong>6.5GB+ 内存</strong>。关掉一个 AI 会话，大约能回收 400~600MB——这就是「明明没开什么程序，内存怎么没了」的真正答案。</p>
<p>所以我的取舍是：</p>
<ul>
<li><strong>按需启用</strong>：只在当前任务真正需要时挂载对应 MCP，用完即关；</li>
<li><strong>会话克制</strong>：后台常驻的 AI 会话控制在最小集合；</li>
<li><strong>能力内置化</strong>：能用 harness 原生能力（子代理、技能、内置工具）解决的，就不引入一个常驻进程。</li>
</ul>
<p>MCP 不是不好，而是「全量常驻」的用法不好。工具的成本不只是订阅费，还有它占住的每一份内存和每一份注意力。</p>
<h2>四、为什么 <a href="http://agents.md">agents.md</a> 这么重要</h2>
<p>如果说前面三节是「减法」，这一节就是唯一的「加法」：<strong>重点维护好 <a href="http://agents.md">agents.md</a> 这一个文件，能解决 AI 协作中 90% 的问题</strong>。</p>
<p><code>agents.md</code>（各家 harness 的叫法略有不同，<a href="http://AGENTS.md">AGENTS.md</a> / <a href="http://CLAUDE.md">CLAUDE.md</a> / <a href="http://codex.md">codex.md</a> 本质都是它）是每次对话都会自动携带的项目级指令文件。地位这么高，但大多数人的用法是错的——要么空白，要么把想到的所有规则一股脑全塞进去。</p>
<h3>Less is more：它是索引，不是全书</h3>
<p>OpenAI harness 文档里对 <a href="http://agents.md">agents.md</a> 的定位其实就一个词：<strong>less is more</strong>。</p>
<p>不要一股脑全放进去——它每次对话都会被携带，太笨重就会稀释注意力，重要规则反而被淹没。正确的定位是：<strong>一本书的索引和重点提醒</strong>，而不是书本身。</p>
<h3>该放什么：根本原则</h3>
<p>只放两类东西：</p>
<ol>
<li><strong>必须遵守的</strong>：项目约定、构建/测试命令、目录结构速查、提交规范；</li>
<li><strong>绝对不能碰的</strong>：危险路径、只读资源、不能自动执行的命令。</li>
</ol>
<h3>危险操作的基线</h3>
<p>把「需要人工确认」的危险操作写成明确基线，比如：数据库写入、生产部署、删除类命令必须先确认。要注意的是——<strong>有的 agent 支持 hook 强制拦截，有的不支持</strong>，所以这条基线既要写进 <a href="http://agents.md">agents.md</a>（软约束），也要尽量落到 hook / 权限配置里（硬约束）。</p>
<h3>加一点魔法</h3>
<p>除了防御性规则，还可以放一些提升体验的「魔法」。比如加一条：</p>
<pre><code class="language-markdown">- 解释复杂内容时善用可视化（表格、mermaid 图、ASCII 图）。
</code></pre>
<p>一行字，模型输出复杂方案时的可读性立刻上一个台阶。这类小魔法积累多了，<a href="http://agents.md">agents.md</a> 就从「规则清单」进化成「协作风格」。</p>
<h2>写在最后</h2>
<p>工具链的演进不会停，但判断标准一直没变：<strong>一个工具值不值得留在你的工作流里，看它省下的时间减去它占用的资源（token、内存、注意力）还剩多少</strong>。</p>
<p>模型选一主一备，harness 用裸的起步，MCP 按需挂载，然后把省下来的精力，全部投给那个 90% 的人都没维护好的 <a href="http://agents.md">agents.md</a>。</p>
]]></content:encoded>
            <author>616657066@qq.com (Vic Wang)</author>
            <enclosure url="https://img.ababy.cyou/images/2026/09/ai-tools/mcp-processes.png" length="0" type="image/png"/>
        </item>
    </channel>
</rss>