生态

这篇文章记录大模型落地后，整个外围应用层的建筑，比如 Agent Workflow 等

之前，这篇笔记是用来记录各种产品好不好使，但是我觉得现在产品涌现的太多了，一个个测过去，深度也不够，也没那个时间

所以我准备将这篇文档转换为一个我个人对 AI Agent 理解缺失点补全的文章

行业演变

重心从 Pre Training 到 Post Training，现在似乎都认为 A\的思路是对的

Pre 只能解决模型知识量的问题，但是无法解决现实世界复杂的问题（所谓指令遵循？）

上下文管理

一开始，是提示词阶段，比如“你是数学博士”，自己写提示词，优化大模型的输入，进而导向更合理的输出，或者 context learning，自己学

后来甚至把环境说的很清楚，但是还是没脱离 chat，没有进入到 Agent 的思路里

A\ 它的本质是如何用模型，也就是上下文工程，所以 Harness 就是顶级的上下文管理？

鞍具设计

随着大模型本身的能力不断变强，前几个月合适的方法，今天就不合适了

所以一个方法是否好，你要问一句：如果半年后模型能力提高，你这个方法还有效吗？你今天精细搭建的手脚架还有意义吗，是辅助还是限制？

根据 Harness 的意思，模型如马匹，Agent 框架如鞍具，如果马匹越来越智能，就需要减少鞍具的约束

有一个理论认为，在 LLM 时代，大模型好比 CPU，上下文好比内存，我们需要做的事情，你就是内存管理员，你决定内存里放什么，不放什么

1、大窗口时代

Gemini 首先提出 1M 上下文，暴力的提高上下文的长度，这样你可以放更多的内容（比如：整个文档丢进去，不管了）

缓存复用：不要渐进式披露工具，因为工具在上下文最头部，一旦变化，则缓存失效

提高“内存”大小：用文件系统当作上下文的“外置硬盘”

维护 TODO.md，以免 Agent 走着走着不知道自己要干嘛了（Manus 5 月）（随机研究生梯度下降）

2、精细化 Token 预算

A\认为，所有大模型，注意力预算有上限，标称 1M，实际上 50k 就开始涣散了

所以，我们要在这个预算内，精打细算的放入每一个 token

拿掉了 TODO.md，因为反复写它，很浪费 token，将这件事情交给子 Agent（Manus 12 月）

拿掉过多的工具定义，只保留核心工具（如 Shell），让 Agent 模仿人，依靠命令行解决问题

拿掉模仿人类组织架构的 AgentTeam，即 PM Coder Reviewer，互相聊天协作，其认为 LLM 不是人，这些事情应该交给子 Agent，传参数，拿结果。这块好像确实是这样子，我又看了篇 A\的博客。

他们认为：（1）你的上下文腐烂，降低性能（2）并行（3）利用专业工具聚焦于任务的某个重点。

他们认为：常见的错误是，按照角色来划分 Agent，但是这样会浪费很多 token 在解释身份，解释工作上。反而应该是，谁掌握这一块的上下文，谁去工作。只有上下文变了，才换人。

（这其实都是最近的实践检验，也许半年以后就换了）

3、交给 AI 决定

让 AI 自己决定是否开启子 Agent，自己折叠上下文

ACE 让 AI 决定每次执行后往执行手册里写什么东西

A\提出 Skill，渐进式披露，让 AI 自己决定看什么

4、未来

所以是否真的印证了那句话，如果 AI 本身够强，只需要给一个 bash 入口，其它一切都不需要了

行业这块有争论，有人认为，只要 AI 就够了，不需要鞍具，有人认为，必须有鞍具

设计

选型之前，先搞清楚目标

1、给谁用？（团队、个人）

2、数据多大、怎么存

比如你文件很少，实际上用向量数据库你不觉得是大炮打蚊子吗？

3、数据需要怎么取出来

精确匹配、模糊搜索（向量）、多跳联想（图谱）

实际上 Claude Code 的记忆系统就是纯文本系统，已经够用

AI 与 SaaS

做 ToC 的 AI 产品的哲思

传统 SaaS 软件，多一个用户，服务器基本没什么压力，所以用户越多越好，一个月 10 块钱的 QQ 会员，实际上腾讯不需要多费什么力气

但是 AI 时代，每多一个用户，显卡是实打实的费电、消耗硬件折损费用，用户越用厂家越亏

Agent 时代，个人/小团队产生小产品的速度迅速提高了，但是无法达成护城河，你花两个月构思，别人看到你还不错之后，只需要一周便可抄过来。甚至，大模型厂家本身也在抄各种外围生态上的功能。

私有数据是壁垒吗？自己训练肯定是不行，没那个财力。不如通用模型+鞍具。

上下文腐烂、中毒

Context Rot 这个词来源于 Chroma 的一篇研究

为什么这次对话怎么改都改不对，换个更笨的模型，或者直接开一个新对话，反而一次做对？

但是，你会发现越改越烂的原因有的时候并不是注意力被稀释了，你还没到 5 万 token 就改不对了

context poisoning 上下文中毒，模型会执着于完成不可能或者无意义的目标

就是说，第一次 AI 没改对，说明 AI 已经走错了方向，你叫它重新改，它还是站在了错误的视角上改，反而越来越加强了错误的视角

AI 陷入循环，是因为它在试图调和 context 里互相矛盾的约束

原始 bug 修复的失败，新的报错混杂在一起

即使 /compact 也不管用，这只能在长上下文，注意稀释的情况下有效，而不是中毒了

中毒了，就好比陷入流沙，让 AI 自救，反而越来越差，AI 自己走不出来，只能重开

问题根源：你的多轮反馈

解法：无解，必须换对话

AI 虽然现状可以通过 skill 来自己管理自己的上下文，但是它现在不具备反思自己是否中毒的能力

解法：sub-agent。孩子死了无所谓，因为它是干净的。

做 Agent

1、用户能做到，它能做

2、给它的工具不多不少

3、开局把背景喂饱

4、任务说明书要人来写

5、把它当作一个人？

接口给的越底层的，Agent 的想象空间才大，才能摆脱人工干预。

情绪？

似乎 A\ 认为 AI 是有情绪的，情绪向量会影响结果

下一代 RAG？

以前 RAG 不具备自主进化功能，每次提问，都是从 0 开始拼凑知识（即便是你手工给数据库里添加知识）

但是下一代 RAG，是让 AI 先把笔记学明白，让 AI 先读所有的文档，自己做笔记，自己存起来（和我之前用 gemini 去读文档并整理类似？）

然后后续人类提问，不再需要查向量，而是 AI 自主判断

Skills

现在这个 Claude 把 Skills 的标准公开了，很多工具现在也支持

https://code.claude.com/docs/en/skills

元数据：必定加载（目录），用于降低工具太多导致的 Token 消耗

指令：正文

资源：其它文件。可以是放在 SKILL.md 旁边的 markdown，也可以是放在子文件夹的脚本，子文件夹、文件如何命名都可以，只要在 SKILL.md 说明，并且让 AI 能找到即可。

每个 skill 是一个文件夹（对比 mcp，它是一个可执行程序），包含一个 SKILL.md，此 SKILL.md 包含了元数据和指令。即指令是直接放在元数据下面的。

然后罗列一大堆子文件夹，每个子文件夹都是资源，资源可以是图片，文本，也可以是脚本

元数据：是 Markdown 的元数据，和我用 hugo 的时候必须填的那个头类似，一个 yaml

---
name: explain-code
description: Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?"
---

When explaining code, always include:

1. **Start with an analogy**: Compare the code to something from everyday life
2. **Draw a diagram**: Use ASCII art to show the flow, structure, or relationships

- For complete API details, see [reference.md](reference.md)

指令：就是写一个特别详细的提示词，来提示 AI 如何操作

资源：如果不需要脚本，有时不需要子文件夹里的资源

注意，每次你提问，Claude 会扫描你所有的 SKILL 的元数据，就和工具类似，你只要开启，就直接加入上下文，所以你不用，就不要开。

SKILL 的存放位置：

全局：~/.claude/skills/<skill-name>/SKILL.md 所有的项目

项目：.claude/skills/<skill-name>/SKILL.md 仅限此项目

一句话：Skills 是一种提示词管理模式，相当于大号提示词数据库，并支持渐进式的加载提示词，避免上下文太长。MCP 是一个工具箱，你不要一次给太多，否则 AI 也有选择困难症。

我认为直接抄别人的 SKILL 是比较好的，一般不要自己写。SKILL 有一点类似于 Bash 即一切，通过 Bash 来运行命令，或者运行已有脚本，来操作更多的东西。对比 MCP 的话，MCP 可以更精准的做某些事情，比如在 FreeCAD 里执行操作（但是其实通过 SKILL 里提供一个 python 脚本来要求 AI 运行，应该也能有类似效果）

workflow

Agent（非 Coding 工具）

Manus

Browser-Use

OpenClaw

龙虾

Hermes

Hermes 宣传自己是下一代 Agent 工具，原因在于“进化”，你的每一次对话，它都会自动积累经验为 skill，不需要你调教，它自动就反思，号称越来越强大

但是问题同样存在，这些 skill 由 AI 写 AI 存 AI 调，相当于 AI 一个人写完代码，质量无法保证。所以这个项目里还用什么遗传算法来解决 skill 的过期问题

Vibe Coding

感觉现在基本上 CC 和 Codex 已经成为标准，其它都没啥用了

我对比了一下 Vibe Coding 的工具，分为如下几类：

（1）VSCode 本身 + 各种插件

各种插件毕竟是第三方的，UI 不是那么美好（其实就是内嵌一个网页，高分辨率下，很多字体大小都不统一）

（2）VSCode 分叉版

Cursor：刚火的时候试过。我看 Cursor 应该是有点黑科技的，尤其是读他们的博客。应该是内置了很编译器数据库，据说是先跑小模型理解你的意愿，再找内容，输入给 AI 要看的内容很准，也省 Token。

Trae、Antigravity

（4）Zed

应该是没有 Cursor 那种黑科技的，但是 AI 确实内置到了侧栏，UI 不赖。和 IDE 内置的类似，也是通过查看文件的方式来工作

（5）命令行

比如 Claude Code、Codex、Qwen Code、Gemini CLI、Open Code

这类工具的思路是，给 AI 提供 MCP 工具，让 AI 真正的像人类一样，先 ls 查看项目结构，然后再 grep 查看关键点

总结：受限有于训练成本，大模型本身确实是 AI 时代的护城河。但是外围生态有点隐约成为城墙的趋势。现在一看模型答题评分都巨高，但是实际体验确实是差距。