像Agent一样思考，3个核心理念

AI编程和Agent有关的概念和观点多如牛毛，让人难以把握重点。

本文试图用3个简单的理念，总结梳理全部重要概念知识，帮助读者形成体系化的认知。

夸张一些说，希望这3个理念的效果，能够像牛顿三定律驱散自然规律的迷雾那样，驱散你看到的Agent世界的迷雾。

Nature and nature‘s laws lay hid in night;
God said: Let Newton be! 

And all was light.

一、上下文至关重要

第一个理念：上下文至关重要(Context is First)。

如果说学习使用Agent，哪个观念最重要？我会说：给 AI 提供解决问题所需的最少必要上下文。

先说Why? 为什么是最少必要？

首先说必要。因为必要的信息不给它的话，它就会瞎猜。猜的结果很可能不是我们想要的。 如果你只告诉它给我写一个能赚钱的APP，保不准会给你弄出一个啥来。

再说最少。因为给太多了的话，模型可能会降智。由于注意力稀释等原因，上下文塞得越满，塞得越乱，模型就会越笨。

以GLM-5为例，这个模型的标称上下文有200K tokens。 根据实测，当上下文长度在64K(约30%)以内，模型是最聪明的。到了100K(约50%)以上，能感觉到明显的降智。

超过160K(约80%),进入断崖降智区间。

再说How? 如何实现这种最少必要的上下文注入？

 一个好的思路是让AI自己在需要的时候主动地加载它所需要的信息。

这里的两个关键词是：主动加载，在需要的时候加载。

在需要的时候加载有个专业术语叫做懒加载。

和主动加载相反的是被动加载，和懒加载相反的是急加载。

主动加载优于被动加载

• ● 被动加载: Agent框架把信息塞到大模型的上下文中。
• ● 主动加载: 大模型自己决定需要获取哪些信息。

早期使用得比较多的RAG架构，是一种典型的被动加载方案。

框架根据用户的提问，通过关键词索引 或者向量索引 去 知识库中找到 大量相关文本信息。

然后 作为 提问的增强上下文，硬塞给大模型。

与之相对应的，则是搜索工具，这是一种主动加载方案。

大模型根据问题内容，视需要情况主动调用搜索工具，构建关键词来查询相关信息。

很显然，随着模型能力越来越强，我们把更多的选择空间交给大模型自己会更好一些，主动加载方式会越来越有优势。

懒加载优于急加载

• ● 急加载: 在对话刚开始的时候，就将全部相关信息注入到聊天上下文窗口。
• ● 懒加载: 在对话刚开始的时候只注入索引或概要信息，对话进行中根据需要逐渐将详细信息注入到聊天上下文窗口。

比较典型的急加载的例子是 AGENTS.md 和 MCP中的Schema信息。 它们都会在对话开始前全部纳入上下文窗口。

AGENTS.md通常的建议是不超过200行，以便保持上下文窗口的干净清爽。

如果有非常多的个性化配置想写入AGENTS.md，通常的建议是把这些配置分门别类放在不同的Markdown文档下。 然后在AGENTS.md中索引这些文档，让大模型在有需要的时候阅读它们。(变成懒加载)

再说MCP，对于一些工具特别多的MCP，要慎重加载。

例如，接入一个 GitHub MCP Server，93 个工具定义一次性全部塞入 context，约 55,000 tokens。 还没开始干活，半个 context window 就没了。

比较典型的懒加载的例子是 Skill 和 Subagent方式。

Agent 只看到每个 skill 的名称和描述（约 100 tokens/个），只有判断相关时才加载 skill 正文，只有执行到具体步骤才读取引用文件。 这种渐进式披露让 300 个 skill 的 token 消耗也比 3 个 MCP server 少。

Subagent 则是懒加载的另外一种形态。

当主Agent调用Subagent的时候，实际上相当于调用了一个工具。

主Agent传入给Subagent的Prompt信息相当于工具的输入参数，然后从Subagent获取的结果相当于工具的输出结果。

利用Subagent能够一定程度上缓解MCP急加载的问题，方法是让大型 MCP Server 只挂载在 subagent 上。

SubAgent在任务完成后上下文整体销毁，主 agent 永远保持轻量。

主 Agent（轻量，只做调度）
├── Skill: change-report（按需加载）
├── Subagent: GitHub PR Agent
│   ├── GitHub MCP Server（隔离在子 agent 内）
│   └── Skill: change-report（被 subagent 使用）
└── Subagent: 数据分析 Agent
    └── Python REPL / pandas CLI

八种典型上下文注入方式

除了上面提到的一些加载方式，我们总结一下Agent常用的八种典型上下文注入方式的特性。

• ● System Prompt注入: 急加载，被动加载
• ● Human Prompt注入: 懒加载，被动加载
• ● RAG方式注入: 懒加载，被动加载
• ● 工具注入(典型如搜索工具): 懒加载，主动加载
• ● MCP方式注入: 急加载，被动加载
• ● AGENTS.md/CLAUDE.md等文件注入: 急加载，被动加载
• ● SKILL方式注入: 懒加载，主动加载
• ● Subagent方式注入: 懒加载，主动加载

二、Agent喜爱命令行

第二个理念：Agent喜爱命令行(Agent Loves CLI)。

人擅长用 GUI，AI 擅长用 CLI。 这个判断不是偏好，是事实。

为什么 AI 天生适合 CLI？

人类设计 GUI 是为了降低记忆负担——用图标、菜单、按钮来提示功能。 AI 没有记忆负担，它不需要图标，它需要的是结构化的、可组合的、输出明确的接口。

CLI 完美满足Agent的需求。

1. 指令极简：git log --oneline -10 做且只做一件事
2. 输出明确：stdout/stderr/exit code，机器可直接解析
3. 自带文档：--help 随时可查，无需预加载 schema
4. 天然可组合：命令行管道让 Agent 能链式解决复杂问题

更重要的是：大模型 在训练数据里见过数十亿行的终端操作、Shell 脚本、GitHub 仓库。 它对 git、gh、docker、duckdb 等常用工具命令行形态的 熟悉程度远超任何自定义 MCP 工具。

MCP 和 CLI 对比

以 github MCP 和 gh CLI为例对比，它们的功能是一样的，但是体验差异巨大。

CLI 封装成 Skill 的威力

对于一些比较冷门的CLI，或者自己开发的CLI，大模型训练时没看过足够数据，不具有内置知识。

这时候，最佳实践是将其封装为 Skill，把这个CLI的名字和功能告诉Agent，让Agent知道什么时候用它。

例如，以我创建的wxgzh 这个skill为例，它的SKILL.md文档可以如此简单。

---
name:wxgzh
description:微信公众号文章发布工具。使用wxgzhCLI将Markdown文章发布到公众号草稿箱。触发场景：用户要发公众号文章、配置公众号AppID/AppSecret、生成封面图、Markdown转HTML、多账号管理。
---
常用命令参考

#查看帮助
wxgzh--help

#一键发布
wxgzharticle.md--author你的名字--themeblue--account公众号名称1

#配置管理
wxgzhconfig--account公众号名称1--appidxxx--appsecretxxx

可见性就是信任

这条理念里最被低估的一点：CLI 对人和机器一视同仁。

当 Agent 调用 gh pr create --title "Fix auth bug" --body "..." 时，你在终端里能直接看到这条命令，能理解它在做什么，能立刻发现问题。

而 MCP 的 call_tool("create_pr", {...}) 是一个黑盒，出了问题你得去 MCP Server 的日志里挖。

可见性是可信赖系统的基础。放弃 MCP 的黑盒，拥抱 CLI 的透明。

三、Agent需要反馈

第三个理念：Agent需要反馈（Agent Needs Reward）。

要让 Agent 在持续迭代中不跑偏，就需要在系统中给它提供奖励/反馈信号。

为什么 AI 会跑偏？

没有约束的 AI 就像没有测试的代码——它可能"看起来能用"，但一旦需求复杂、迭代多轮，就开始漂移。 每次迭代，它都在优化"让用户满意"，但用户的满意感往往来自表面顺畅，而非系统正确。

解决方案不是写更多 prompt 去约束它，而是给系统设计客观的奖励信号。 一种不依赖人类实时判断的、机器可验证的正确性评判机制。

三种典型奖励信号

1. LSP（语言服务器协议）— 语法层奖励

LSP 让编辑器和 AI 编码工具能实时获得"代码是否正确"的反馈：类型错误、未定义变量、语法问题，立即报错，立即惩罚。 AI 写出不符合类型规范的代码？LSP 报红。不修好就无法继续。 这是 AI 编码工具（Claude Code、OpenCode、Copilot 、Cursor等）好用的核心基础设施之一——它们都深度集成了 LSP，用语言服务器的即时反馈来持续纠正 AI 的生成方向。

1. TDD（测试驱动开发）— 行为层奖励

TDD 的核心循环：先写测试（定义期望行为），再写代码（满足测试）。

Red（写失败的测试）→ Green（写最小实现通过测试）→ Refactor（优化）→ 循环

对 AI Agent 来说，TDD 是一种天然的奖励信号机制：

• ● 测试用例 = 对期望行为的精确规格说明
• ● 测试通过 = 客观的"正确"信号，不依赖人类判断
• ● 测试失败 = 明确的惩罚信号，告诉 AI 哪里错了

实践中，AI 配合 TDD 的效果远好于"自由发挥"。让 AI 先看测试再写代码，它会朝着明确目标迭代，而不是生成一段"看起来对"的代码。

1. SDD（规格驱动开发）— 架构层奖励 SDD（Spec-Driven Development）是 TDD 的升级版。

先写规格（Spec），规格既是设计文档，也是验证标准。 以非常流行的SDD工具OpenSpec为例，它定义了设计文档 的4层结构：

Proposal（提案层，描述问题背景、目标和可行性分析）
    ↓
Specs（规格层，定义系统行为、接口和约束的正式规格）
    ↓
Design（设计层，技术方案和架构设计文档）
    ↓
Tasks（任务层，可独立实现和验证的工作单元）

每个 Task 都有配套的验证方式——类似 TDD 中的测试，但粒度更大，覆盖整个功能模块甚至系统行为。

对 AI 来说，SDD 提供了从需求到实现的全链路"奖励信号"：

• ● AI 看着 Specs 写代码，Specs 里的约束就是边界
• ● 每完成一个 Task，验证步骤告诉它是否走对了方向
• ● 代码与规格不对齐？惩罚，返工

SDD 解决了 AI 编码中非常棘手的问题：在长周期多轮迭代中保持方向一致性。

"Vibe Coding"之所以会产出大量 AI 代码垃圾，正是因为没有规格约束，AI 每次都在随机漂移。

类比：建筑师有建筑图纸（规格），施工团队按图施工，验收时对照图纸检查。

奖励信号设计原则

好的奖励信号有三个特征：

1. 客观可验证：不依赖人类主观判断（测试要么通过要么失败，没有"差不多"）
2. 及时反馈：问题发生时立即告知（LSP 实时报错，比代码 review 快得多）
3. 粒度适当：太细（每行代码都要验证）或太粗（整个项目最终验收）都不好

三种机制叠加使用，形成从语法到行为到架构的完整约束体系。

总结：三条理念，一个核心

这三条理念有一个共同核心：不要试图用 prompt 控制一切，而是设计系统让 AI 自我校正。

最好的 Agent 系统不是那个 prompt 写得最精妙的——而是那个能给 AI 大模型 提供清晰上下文、合适工具、客观反馈的系统。

给它信息，给它工具，给它反馈。然后让它工作。