AI应用初识

一、概述一个AI应用自底向上可以大致分为四层LLM大语言模型纯粹的模型能力。算法团队负责Main Loop(react)AI基建让模型具备基本的交互能力reason-act。研发团队负责Agent给模型配备场景相关的信息、工具使之可以承担具体的场景工作。最初是由研发团队负责现在界限模糊了部分产运成员可以自主开发Application产品可以是单Agent应用也可以是多Agent应用二、LLM根据训练数据得到的一个概率模型模型本身只支持一来一回的简单交互问一句答一句根据训练数据不同模型擅长的内容也不同比如写代码常用claude和glm写文章常用ds三、Main Loop学术界通常称为 ReAct (Reason Act) 工程界通常称之为 Agent Loop 或 Main Loop本质上它就是一个循环基本概念请求模型时的两部分基本内容参数messages一个消息列表每个消息有角色user | assistant和内容最新的一条即表示最近的用户输入SPsystem prompt系统提示词是一条Role System的消息可能放在messages也可能单独存放取决于模型api3.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 提示词工程与上下文工程在模型应用的探索初期大家倾向于把所需的信息一次性灌输给模型以期它能够做更多的事情但是模型可以接受的入参长度有限可接收的token长度即便在模型入参长度允许范围内入参的信息越多模型的表现就越不尽人意模型幻觉概率增加 上下文腐坏于是为了让模型表现更好有了围绕sp描述、mcp描述甚至是用户输入内容的调优尝试上下文比提示词的范围大但提示词工程和上下文工程做的事情没有本质区别但是我们发现当业务场景复杂起来之后在此运行框架的基础之上再锱铢必较也无法带来质变就这一亩三分地你的MCP描述再精简它也得把功能描述清楚而这套机制中MCP都是一股脑给过去的。3.3 SKILL在上下文容易腐坏背景之下渐进式披露的概念被引入在我们这个讨论的范围内你可以把它约等于SKILLS3.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.2CLI一个应用程序的命令行接口它其实是图形界面之前的产品形态在AI这波浪潮里又重获新生主要原因有模型与图形界面的交互很难实现模型天生对命令行这令繁琐又明确的东西很擅长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.3bashbash方式实际上是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就可以定义为具备特定场景的知识和工具能够解决特定场景问题的基于模型能力的一套系统组合五、ApplicationAI相关的产品我认为大致分这么几种基本基于模型能力的新应用这些都是在模型早期的尝鲜型应用最简单的比如聊天机器人这种基于Agent能力的新应用特定场景的工作方式被AI重塑时产生的工具型应用比如AI修图、生成视频等等真需求的AI和AI假设前提是我认为工具的爆发无法催生新的真需求AI使用AI工具重构原流程AI使用AI思路重构原来产品