今天不谈广告，最近接触了很多业内对Openclaw和Skill的光热，作为一个IT科班出身转行AMZ的从业人员来说
先给一个结论 
所谓的智能体，就是所有不需要智能的部分组成的一种结构。 而最近爆火的skill本质上是一种新瓶装旧酒的换皮而已。
—————————
###大语言模型
在了解这些之前，先明白，什么是大语言模型
一切的开始来源于语言模型，最开始的语言模型就是人工智障。但随着参数加上各种发展的变化增加，在经历过某个临界点以后，出现了所谓的“智能”。
用专业一点的话来说，就是这个临界点是：Transformer 架构提供并行与长程能力 + 万亿级数据喂入 + 超算级算力支撑 + 预训练–微调–RLHF 三段式训练 + 规模突破触发能力涌现
而因为智能的出现，为了和之前的人工智障进行区分，于是乎出现了第一个名字“大语言模型”
也就是LLM -large language model
但 LLM 的核心能力其实只是「文字接龙」：输出上一个字符时，匹配并生成下一个字符。
比如它能整合出「今天我妈包了 30 个韭菜馅的饺子」这类信息，却无法直接响应实际需求，依旧像个「智障」。
但是这样的话并没有解决什么需求，仍然像个人工智障
直到有人将信息拆分为「一问一答」的对话形式：
问：今天我妈做了什么？
答：包了 30 个饺子。
通过人为划分对话角色，LLM 实现了第一个实用化的「智能场景」—— 对话。
 
—————————
假设你是一个BOSS，LLM就是你手底下的员工，不过这个员工只能通过一问一答回答你的问题，类似于一个产品解说员。
你可以通过提问去了解相关的信息，但是你问什么问题就只能回答什么问题，**不能追问不能追问不能追问！**

记住这个重点：不能追问

但是你是花钱雇他干活的，只能一问一答怎么能行。于是乎你想尽办法去榨取他身上的价值，于是你思考该怎么做呢？

比如你找LLM问：“我发现现在的年轻人都喜欢二次元，我想把我们的产品和二次元进行结合，我们有什么产品可是适合年轻人的？”

你把你的提问起了个洋气的名字“prompt(提示词)”，然后LLM听到你的要求以后，发现你的要求由两个部分组成
*背景信息：我发现现在的年轻人都喜欢二次元，我想把我们的产品和二次元进行结合
*指示要求：我们有什么产品可是适合年轻人的？

于是为了区分，你把这两块进一步区分，重新改了个名字
context（上下文）-背景信息：我发现现在的年轻人都喜欢二次元，我想把我们的产品和二次元进行结合
prompt（提示词）-指示要求：我们有什么产品可是适合年轻人的？

有时候你想对LLM进行追问，但是上面又提到了，LLM不能进行追问，于是你想了个办法，每次问LLM之前，都把之前的要求（对话历史）进行叠加，把上面的提问和回答都放在context里面，进行提问达到追问效果。

比如原来是：
“目前产品XXX，新品XXX；今年我们要做20%的增长，你给我一个方案规划看看怎么能做出来”
LLM给出结果以后，追问“我还想要有10%的利润增长”
变成了：
“目前产品XXX，新品XXX；今年我们要做20%的增长，现在有一个基础方案“LLM第一次输出的方案”，除此以外，我还想要有10%的利润增长”

以此来伪装成多轮对话。
你给这种方式起了个名字：memory，意思是大模型的记忆功能
而Memory还可以再次调用大模型进行总结， 从而进行记忆压缩，进而减少上下文的长度.
 
于是乎，LLM从最开始只会做词语接龙的实习生变成了一个可以对话且不断追问的初级牛马
 
慢慢的，你不再满足于只是询问LLM一些基础的问题，你还想他给你一些行业最新的动态。
但是做这些需要联网，那怎么办？LLM不会上网，他只会给你回答问题，讲解自己的产品。
但是由于他无论如何都会回答你的问题，那么就会利用文字拼接能力开始胡说八道，或者利用他的知识库给你提供一些过时的消息。
比如问：给我一个最近比较火的新闻
答：北京申奥成功啦/天翼3G就是快！ 
 
 
于是你想，不会上网可以教啊！于是你给LLM准备了一台可以上网的电脑，但是你发现，LLM不会用电脑，他只会回答你的问题，本身只会词语接龙，其他啥也干不了。
于是你又雇了一个人A，你告诉LLM，让他需要查找资料的时候告诉A，让A去查完资料把资料告诉LLM
但是你发现，这样子显得有点蠢，成本好像有点太大了，我不如自己去查。
 
 
于是为了节省成本，你找人写了一个对话程序，让这个程序代理你去和LLM沟通并且完成搜索任务。
原来整个过程是：
**你提问LLM——LLM去找A搜资料——LLM总结资料——LLM回答你问题**
现在整个过程变成了：
**你提问程序-程序回答结果**

==把LLM找A搜资料，总结资料进行了一个整合，从面相LLM变成了面向这个程序了==

这一下子就好像让这个程序拥有了智能，并且这个智能还能利用工具。
你给这个程序起了个名字“Agent”
甚至很多早期这个agent所谓的智能，实现的逻辑不过是多加了一段prompt而已
例如提问的时候加一句“你是一个高级运营专员”，然后加上你需要提的问题，让LLM的回答更加贴近这个领域，实现Agent假象，宛如一场诈骗。
——————
回到上面的案例，既然这个Agent能上网搜索内容了，那是不是也可以增加一个搜索本地文档或者检索数据库的能力呢？当然没问题，只不过和传统搜索数据库不同的是，要使用向量数据库，把语义相近的片段找出来进行匹配。

你把通过语义匹配向量化信息，并加入上下文增加生成内容可靠性的办法，叫做Retrieval Augmented Generation-检索增强生成 
而刚才那个联网搜索也起个名字：Web Search
而 为了让scope显得更大一点，两种办法简单一些拼写，成为了RAG和Search
获取模型参数以外的信息能力

此时工作的整体架构变成了 你和LLM中间隔了一层Agent的程序，用于减少你和LLM直接沟通的次数，并且处理一些LLM无法操作的东西，包括但不限于搜索信息，文件读取，脚本执行等等

但是此时又有一个问题，如果我们聚焦于Agent和大模型的对话过程可以发现， 如果一直用自然语言沟通，那这个agent的代码就很难用程序来实现，完全无法预测大模型如何去理解描述你的需求并调用工具执行。
所以为了保险起见，我们去制定一个约定，让大模型按照指定的固定的格式来进行回复，比如json，这样程序就能很清晰的去进行解析。
你给这种agent和大模型之间关于工具调用所约定的对话格式，叫做function calling，说人话，就是上面的约定而已，简称FC。

回归agent本身，这时候的Agent在工具的实现上，目前来说还写在了agent主程序上，没有和核心功能解耦。
也就是说，系统各部分间还存在不必要的强依赖，无法让模块独立、进行灵活变化
而如果去单独写一个程序，让主程序去调用这个服务，就有需要约定的规范了，比如约定好tools/list的方法，tools/call的方法，这时候你给这个方法又起了个名字叫https://modelcontextprotocol.io/
也就是MCP-模型上下文协议

于是，架构就变成了下面这样，LLM成为了一个只能说话不能做的智者，而MCP服务就是能提供各种工具的程序集，中间的Agent还是那个传话筒，把大模型的话转换成调用工具的代码，然后再把工具调用的结果再原封不动的传话给大模型，然后经过大模型思考以后，把结果输出给你这个boss，主打一个信息的搬运工

 
 
此时聚焦于Agent和你的对话之间，也就是User，可以发现，虽然最底层依然是文字，但是在交互上可以非常丰富多彩了。可以是CLI这种命令行窗口，也可以是IDE编程工具，还可以是更为通用的桌面助手比如最近很火的openclaw。

 
无论什么形式的智能体，换了什么名字，都有一个统一的缺点：
比如我要翻译一个PDF然后以word的格式保存下来，如果你直接把这个需求描述给Agent，让他自己策划整体的流程，会发现这个流程会非常浪费token.
整个流程中，实际上要经历多个步骤：
提取检索阅读PDF-输出PDF的内容-根据PDF内容进行匹配翻译-输出翻译结果-保存Word结果

而提取匹配和保存结果这个完全可以用程序进行解决，中间的翻译直接和LLM沟通，整个流程就不用再和Agent进行沟通，可以节省大量的token 
而固化这样的流程，比较专业的可以通过编程的方法来实现。为了方便编写这种链式的任务，产生了一个新的编程框架：Langchain。而为了照顾非程序员用户，以低代码的形式实现这个目的，产生了另外一种方式，就是在页面上傻瓜式的拖拽，上手难度非常低。而这种形式又有一个名字：workflow，即工作流

但是此时又有一个新问题，如果此时处理的原始文档不仅有PDF，还有word,execel,PPT等，输出的格式也可能是PDF，markdown，甚至是图片等，此时单一的工作流就不再适用，也不可能说给每一套都写一个工作流，这也太麻烦了。
当然也可以说写一堆if else做判断，但是如果只是以自然语言的方式触发任务，不牺牲普通用户体验的话就不好用程序去判断分支了。

这时候可以准备一个目录，把所有可能涉及到的转换脚本都放在这个目录合集里面，比如提取PDF、提取图片；转换PDF、转换图片等脚本。
再给这个目录写一个统一的说明文件，把整体流程描述清楚
例如：
1-根据用户输入的文件格式，寻找合适的脚本进行内容提取。
2-根据用户的需求，翻译成指定语言。
3-根据用户要求的输出格式，寻找合适的脚本输出为指定格式的文件。
并且告诉Agent，根据文件的格式灵活选择脚本进行执行命令。而且在给Agent下达命令任务之前，添加上一个固定prompt：**先读取SKILL.md中的要求，然后遵守这个要求的前提下，完成下面用户的任务**
这样整个过程就既保证了一定的灵活性，也变得比较可控。
但是这样还可以进行优化，我是不是可以提前在Agent中写入一段死程序，要求完成任务之前必须读取这个Skill.md。这样就不用每次都加这么一段命令，而是将命令固化到整个程序完成之中。 
发现没有，虽然这就是把提示词换个地方储存起来，但是毕竟是技术的“更新迭代”。于是你给这个起了个新名字，就叫做Skill，即Agent的技能，其实就是基础的模块封装（prompt加载器）

此时整个架构成了这个样子。
 
 
 
而如果有某个复杂的任务需要处理的话，可能Agent的上下文会变得非常大，一个Agent会有很多个子Agent去参与流程，而对于这些子Agetn，产生了一个新的概念：SubAgent.

比如我之前做的一个产品设计Agent中，其中市场调研分析本质上就是一个个的SubAgent，市调然后出结果，然后再出方案分析，图品设计，1688类似竞品成本对比等等
对于一些独立的子任务，可以单独在这个Agent中进行完成，在本质上是做了上下文隔离的作用。子Agent产生的上下文，不会保留在主Agent中，仅此而已。
 
——————————
每个概念出来的时候，都有大量的文章视频等吹捧，然而这些概念的设计在我看来，用高情商的话说：技术发展的中间产物。
低情商：拉胯。
所有的这些都离不开大模型和我们之间的提示词，目前的技术无非是帮助我们更好的填充提示词罢了。
这就是为什么开头说的，Agent反而是最不智能的部分组成的，因为本身是帮助LMM更好的掌握一些固定的工具产生的流程集合而已。
LMM做判断，Agent去实施，以此来提高工作效率。
未来一定还会有更方便的，更适合普通人的方式产生。

越是强大的，自己能处理问题的Agent，背后消耗的token越大，这和目前生产力算力息息相关，包括电力供应等也都有关系。
所以目前AI整体在生活工作上仍旧处于未来可期的一个状态（毕竟国内的实习太学生真的性价比太高了）
用群友的话评价是：3000块的大学生可能不好用，但是3000的AI包不好用的。
什么时候硬件上面有大的进步或者某个生产级别的大模型能在一台普通的家用电脑上部署的时候，才是AI时代真正来临的时候。
clawdbot为什么这么火？除了营销因素以外，本质上和ClaudeCode、CodeManus这些智能体是没有什么太大的区别的。就只是因为它能链接社交软件，配置定时任务，有个页面把skill可视化并管理。首次让普通人也觉得它像一个智能体，而不是躺在电脑上的一个服务功能。
便利，才是AI真正的意义。

而目前亚马逊也好，其他跨境电商平台也好，AI真的能替代的是什么呢？我可以很明确的告诉你，在2026年现在这个时候，我所见到的行业的AI运用其实也非常浅显，依旧担任着超级助手的职责。
类似于在一台手术中，医生不用说话，一抬手就能精准无误给他递手术工具的辅助护士。非常厉害，但是也仅此而已
平时看到很多营销，包括也进过不少电商Ai实战群，发现他们引以为豪的无非是用AI帮助管理一下库存，写一下listing，做一些图而已。至于产品战略规划，广告规划调整，我只能说有用但是不多。
而这些，2023年已经能够全部实现了，可以看到业内对AI实际上也没有太多的落地。哪怕我很自豪的说我站在业内AI的一线，能让AI帮我写链接，优化图片，设计视觉，部署广告计划，一键发货，广告复盘等等等，最多也就是一个人干一个团队的活，但是我知道，灵魂还是因为我自己，我所用AI做得，无非是节省了一个又一个3000块的实习生，仅此而已。
看起来好像很厉害，但是会本地部署AI，自己用代码写小工具，多年亚马逊操盘经验，团队管理经验的人，要凑齐这么一个团队，可不是5000美工+8000运营+3000助理能搞定的，实际性价比看似高实则很低。（虽然在义乌也混不到高收入倒是）

不过话又说回来，乔布斯发布苹果4S之前，没人真正看到了智能手机的未来，或许现在和未来，只是欠缺一款划时代的产品，仅此而已。