AI 工具怎么选：模型、Harness 与那个被你忽视的 agents.md

Sun, 06 Sep 2026 00:00:00 GMT

为什么现在才开始写 AI 工具教程

AI 浪潮已经翻涌了这么久，各种教程、测评、安装指南满天飞，我却一直没动笔。不是没东西可写，而是过去这段时间大家（包括我）都在摸着石头过河：

看到这个工具不错，装！看到那个框架很酷，装！折腾了一圈下来，工具箱越来越满，真正交付的东西却没变多。

工具的堆叠不会自动带来生产力，反而会拖累所有东西——token 花得更快、上下文更乱、任务更容易跑偏。所以这篇教程不想罗列「必装清单」，而是想讲清楚三个决策：选什么模型、选什么 harness 座驾、维护哪一份配置。想通这三件事，90% 的折腾都可以省掉。

一、模型怎么选：GLM 和 GPT

先说结论：日常主力我推荐 GLM（智谱） 和 GPT（OpenAI） 两条线。

模型	适合场景	一句话评价
GLM 系列	编码主力、长任务	国内直连稳定，Coding Plan 性价比高，订阅活动也多
GPT 系列	复杂推理、通用兜底	综合能力强，适合作为第二引擎交叉验证

几个务实建议：

订阅走官方渠道。模型账号的「代充」「共享」渠道水很深，轻则掉额度，重则泄漏你代码库里的敏感信息——对工程师来说，后者是不可接受的。
一个主力 + 一个兜底就够了。模型的边际收益递减很快，与其集齐七八个模型，不如把一个模型的上下文管理、任务拆分玩明白。
活动价可以薅，但别让「薅活动」本身变成一个工程。

二、Harness 座驾怎么选：很美，但不适合所有人

选完模型，下一步是选 harness（座驾）——也就是承载模型的 CLI / IDE 框架。ECC、Superpowers 这类增强方案确实很美：自动记忆、自动技能加载、一堆预设流程，看起来一装就起飞。

但我得泼一盆冷水：这些东西并不适合所有人，尤其不适合新手。三个真实缺点：

Token 消耗多。增强框架会往每次对话里塞大量系统提示、记忆、技能说明，你还没开始干活，上下文已经烧掉一大截。
限制模型能力。过度的预设流程等于替模型「想好了」做事方式，模型自己的判断力反而发挥不出来。
任务跑偏。自动化链条越长，单点错误的放大越严重——一个小指令被误解，整条流水线都会带着错误往前跑。

新手正确的路径是：先用裸 harness 把基本功练扎实（怎么写提示、怎么拆任务、怎么审查输出），再按需加装增强。配置是你自己的，能力才是你自己的。

三、为什么我放弃使用 MCP

这是个反直觉的决定——MCP（Model Context Protocol）明明是 2025 年之后最热的生态，工具一个接一个接入。但我的实际体验是：MCP 的进程膨胀问题，正在悄悄吃掉你的机器。

看一个真实案例。后台同时挂着多个 AI CLI 会话（ZCode / claude / codex / omp / ChatGPT 桌面版），每个会话都会把全套 MCP 各起一份进程，实测副本数：

MCP 服务	副本数
dbhub	×46
context7	×44
deepwiki	×37
codegraph	×31
filesystem	×10

合计约 168 个 MCP 进程：

对应 node×96 + cmd×101 + npx×28，每个实例 50~110MB，总计吃掉 6.5GB+ 内存。关掉一个 AI 会话，大约能回收 400~600MB——这就是「明明没开什么程序，内存怎么没了」的真正答案。

所以我的取舍是：

按需启用：只在当前任务真正需要时挂载对应 MCP，用完即关；
会话克制：后台常驻的 AI 会话控制在最小集合；
能力内置化：能用 harness 原生能力（子代理、技能、内置工具）解决的，就不引入一个常驻进程。

MCP 不是不好，而是「全量常驻」的用法不好。工具的成本不只是订阅费，还有它占住的每一份内存和每一份注意力。

四、为什么 agents.md 这么重要

如果说前面三节是「减法」，这一节就是唯一的「加法」：重点维护好 agents.md 这一个文件，能解决 AI 协作中 90% 的问题。

agents.md（各家 harness 的叫法略有不同，AGENTS.md / CLAUDE.md / codex.md 本质都是它）是每次对话都会自动携带的项目级指令文件。地位这么高，但大多数人的用法是错的——要么空白，要么把想到的所有规则一股脑全塞进去。

Less is more：它是索引，不是全书

OpenAI harness 文档里对 agents.md 的定位其实就一个词：less is more。

不要一股脑全放进去——它每次对话都会被携带，太笨重就会稀释注意力，重要规则反而被淹没。正确的定位是：一本书的索引和重点提醒，而不是书本身。

该放什么：根本原则

只放两类东西：

必须遵守的：项目约定、构建/测试命令、目录结构速查、提交规范；
绝对不能碰的：危险路径、只读资源、不能自动执行的命令。

危险操作的基线

把「需要人工确认」的危险操作写成明确基线，比如：数据库写入、生产部署、删除类命令必须先确认。要注意的是——有的 agent 支持 hook 强制拦截，有的不支持，所以这条基线既要写进 agents.md（软约束），也要尽量落到 hook / 权限配置里（硬约束）。

加一点魔法

除了防御性规则，还可以放一些提升体验的「魔法」。比如加一条：

- 解释复杂内容时善用可视化（表格、mermaid 图、ASCII 图）。

一行字，模型输出复杂方案时的可读性立刻上一个台阶。这类小魔法积累多了，agents.md 就从「规则清单」进化成「协作风格」。

写在最后

工具链的演进不会停，但判断标准一直没变：一个工具值不值得留在你的工作流里，看它省下的时间减去它占用的资源（token、内存、注意力）还剩多少。

模型选一主一备，harness 用裸的起步，MCP 按需挂载，然后把省下来的精力，全部投给那个 90% 的人都没维护好的 agents.md。

Vic's Blog