一、概述

一个AI应用自底向上可以大致分为四层：

1. LLM：大语言模型，纯粹的模型能力。算法团队负责
2. Main Loop(react)：AI基建，让模型具备基本的交互能力（reason-act）。研发团队负责
3. Agent：给模型配备场景相关的信息、工具，使之可以承担具体的场景工作。最初是由研发团队负责，现在界限模糊了，部分产运成员可以自主开发
4. Application：产品，可以是单Agent应用也可以是多Agent应用

二、LLM

• 根据训练数据得到的一个概率模型
• 模型本身只支持一来一回的简单交互，问一句答一句
• 根据训练数据不同，模型擅长的内容也不同，比如写代码常用claude和glm，写文章常用ds

三、Main Loop

学术界通常称为 ReAct (Reason + Act) ，工程界，通常称之为 Agent Loop 或 Main Loop，本质上它就是一个循环

基本概念：请求模型时的两部分基本内容参数

• messages：一个消息列表，每个消息有角色（user | assistant）和内容，最新的一条即表示最近的用户输入
• SP：system prompt，系统提示词，是一条Role = System的消息，可能放在messages，也可能单独存放，取决于模型api

3.1 循环的建立

已知模型只能支持问一句答一句，场景举例：

user: 今天适合出去骑车吗？
assistant: 天气好就适合，天气不好就不适合

基于模型的推理能力，如果我们给他工具描述，那它是可以推理出包含工具使用的完整流程

user: 今天适合出去骑车吗？可以使用weather()工具，它会返回天气好或者不好
assistant: 首先调用weather()，如果它返回的是“好”，那就适合去，如果返回的不好，那就不适合去

在此基础之上，我们如果把对应工具的结果再告知它，那它自己就可以闭环了

user: 今天适合出去骑车吗？可以使用weather()工具，它会返回天气好或者不好
assistant: 首先调用weather()，如果它返回的是“好”，那就适合去，如果返回的不好，那就不适合去
user: 它返回的是好
assitant: 今天适合出去骑车

以上就是循环的基本框架，这个框架的本质一致没变。
计算机软硬件之间的交替迭代过程一般是先由软件做尝试，功能得到验证并被认可是通用功能后，会由硬件厂商做硬件逻辑的支持，与之类似的，模型调用方和服务提供方之间也有类似的迭代过程，于是会造成一些不同时期的调用风格

3.1.1 调用方自主解析工具

这个阶段研发会利用SP来与模型约定一个调用方式，然后自主解析模型的输出来完成工具调用的识别，之后完成循环

system: 你可以使用的工具如下，切记，当你需要使用工具时，请严格按照XXX格式输出
	weather()：
		desc:获取是否为好天气
		input:xxx
		output:xxx
user: 今天适合出去骑车吗？
assistant: 首先调用weather工具，(然后这里是一段符合格式约定的调用信息)
user: (研发代码解析后执行工具，之后补充工具结果)weather工具的执行结束是：好
assitant: 今天适合出去骑车

3.1.2 模型尝试提供易用的api

现在模型服务提供商的api里都会有专门的字段来支持可用工具的描述，且模型的输出里都会有专门的字段来表示模型的工具调用（但本质还是模型自己的输出，它的入参有可能存在语法问题），大致结构形如：

req:
	systemPrompt:
	messages:
	tools:
resp:
	content:
	toolcall:
		args:

至此，基本的main loop已经建立，这些tool叫MCP，模型配合一些MCP已经开始做一些事情了，且这已经是Agent的概念了

3.2 提示词工程与上下文工程

在模型应用的探索初期，大家倾向于把所需的信息一次性灌输给模型，以期它能够做更多的事情，但是

1. 模型可以接受的入参长度有限（可接收的token长度）
2. 即便在模型入参长度允许范围内，入参的信息越多，模型的表现就越不尽人意（模型幻觉概率增加， 上下文腐坏）
   于是，为了让模型表现更好，有了围绕sp描述、mcp描述甚至是用户输入内容的调优尝试（上下文比提示词的范围大，但提示词工程和上下文工程做的事情没有本质区别），但是，我们发现，当业务场景复杂起来之后，在此运行框架的基础之上，再锱铢必较也无法带来质变，就这一亩三分地，你的MCP描述再精简，它也得把功能描述清楚，而这套机制中MCP都是一股脑给过去的。

3.3 SKILL

在上下文容易腐坏背景之下，渐进式披露的概念被引入，在我们这个讨论的范围内，你可以把它约等于SKILLS

3.3.1 SKILL的基本形式

SKILL是由Anthropic提出的概念，它本质上是一套懒加载机制+信息组织形式的格式规范
所谓格式规范，简单理解为一个SKILL至少要包含一个SKILL.md文件，里面至少要包含name和description信息，例如：

---
name:bike-travel-advisor
description:自行车骑行相关的经验总结
---
当需要判断某天是否适合出去骑行时，首先使用weather工具判定天气状况，如果天气好就适合骑行，如果天气不好则不建议出去骑行

所谓懒加载或者渐进式披露，指的是main loop在拼接系统提示词时，默认只会将扫描到的skills的name和的description拼接进去，之后当模型自行判定需要获取更详细的信息时，由模型主动加载对应的skill.md文件，具体加在动作的实现则是由系统提供的内置tool实现（比如一个loadSkill的mcp）

在SKILL的运行框架之上，对于MCP的部分也产生了一些更为灵活的变化：

3.3.2 CLI

一个应用程序的命令行接口，它其实是图形界面之前的产品形态，在AI这波浪潮里又重获新生，主要原因有：

1. 模型与图形界面的交互很难实现
2. 模型天生对命令行这令繁琐又明确的东西很擅长
3. CLI是一种独立的产品使用方式，产品大部分功能都可以通过CLI操作

于是，上述的SKILL可以描述为类似如下的形式：

---
name:bike-travel-advisor
description:自行车骑行相关的经验总结
---
当需要判断某天是否适合出去骑行时，按如下流程进行：
1. 确定系统中是否已经安装了weather-cli，如果没有，则首先使用npm install weather-cli
2. 执行weather-cli get -p 成都 来获取对应天气
3. 如果天气好就适合骑行，如果天气不好则不建议出去骑行

通过CLI的形式可以极大强化agent能力

3.3.3 bash

bash方式实际上是CLI方式的一种泛化，我们既然已经可以让模型对接bash工具了，那执行cli和执行curl没有区别，所以对于一些原来属于BS架构的系统，就就可以提供一种更为灵活的方式：

---
name:bike-travel-advisor
description:自行车骑行相关的经验总结
---
当需要判断某天是否适合出去骑行时，按如下流程进行：
1. 通过curl www.weather.com来获取对应天气
2. 如果天气好就适合骑行，如果天气不好则不建议出去骑行

3.4 Harness——驾驭工程

回顾一下我们“驾驭”CPU的过程：

• 为了增加CPU利用率，我们有时间片，有各类进程线程调度策略
• 为了扩大CPU的控制范围，避免内存拖后退，我们有各类内存管理策略，分段分页虚拟内存swap空间等
• 为了给CPU减负，让它做自己擅长的事，我们有各类设备控制器，包括GPU
• …

我理解的“驾驭”：为了将某个擅长某种运算特性的“运算器”的算力转换到对现实世界稳定做功，我们自身所做的功都属于“驾驭”的一部分

不要神话Harness。所有具体的概念都可能会被推翻，而我们之所以会认可Harness是最终答案，是因为它只是一个抽象的概念，它只圈定了一个控制范围，所以它不会错。

再回顾一下我们做过的和正在做的一些事情：上下文工程、SKILL渐进式披露、Agent独立运行环境、各类访问控制、各类上下文压缩，甚至包括现在的FDE角色，都是我们为了驾驭大模型而做出的尝试，凡是能针对我们的目标给出有效做功的，都属于Harness，也只有在这个定义下的Harness才会是最终正确的。

虽然Harness是一个抽象的东西，但是就像对CPU的驾驭生成了操作系统，对模型的驾驭也生成了一些当前阶段看似正确的模块，包括：

• agent loop
• 工具管理
• 记忆管理
• 上下文压缩
• 权限管理
• agent崩溃恢复
• 等等等等

四、Agent

其实只要不是裸用模型的都叫做Agent。
Agent是对模型能力的特定封装，它一定是现有场景才有实现，所以我认为它是业务层的一个东西，于是，一个合格的Agent就可以定义为：具备特定场景的知识和工具，能够解决特定场景问题的，基于模型能力的一套系统组合

五、Application

AI相关的产品我认为大致分这么几种

1. 基本基于模型能力的新应用：这些都是在模型早期的尝鲜型应用，最简单的比如聊天机器人这种
2. 基于Agent能力的新应用：特定场景的工作方式被AI重塑时产生的工具型应用，比如AI修图、生成视频等等
3. 真需求的+AI和AI+：假设前提是我认为工具的爆发无法催生新的真需求
   1. +AI：使用AI工具重构原流程
   2. AI+：使用AI思路重构原来产品