做了三年工厂软件里的 AI 功能，我怎么理解 Agent

文中的经历做了抽象，具体实现不便展开，只讲做法和体会。

前几年我在一家做工厂软件的公司，陆续做过几个和 AI 有关的功能。当时没想过它们算哪种“范式”，现在回头看，正好从简单到复杂排成一条线。这篇先把我试过的几种形态摆出来，再对照现在大家常说的做法，最后讲讲记忆：怎么让一个 AI 工具越用越准。

一、我试过的几种形态

1. 一次调用：把一段话变成结构化的数据

最早做的是把一段语音整理成一条条任务，自动填进任务系统。它本质上就是文字的结构化：模型跑一次提示词，提取信息、编排信息，输出一段 JSON。没有循环，也没有工具。

很多场景用这一步就够了，不必一上来就做 Agent。

2. 分流 + 转参数：用自然语言查数据

后来做过一个让老板用自然语言查生产数据的助手，用低代码的 AI 工作流平台搭的，一个节点一步：先判断这句话属于哪个业务模块，再提取查询条件，最后转换成系统接口要的参数。模型的作用只是把人话转成统一的结构，查询本身还是调系统接口。

这类做法只能回答事先设计好的那几种问题。难点也不在 AI，而在“用户到底想看什么”。

3. 一次提取 + 人确认：识别手写单据

车间里很多信息还写在纸上。拍一张照片，让模型按固定的 JSON 格式提取出来，再去系统里找到对应的记录，最后给用户一张表单确认。

一个小技巧：手写字常常认不清，可以在提示词里放进这个客户常用的选项，让模型对照着认，准确率会高不少。

4. 通用 Agent：给实施同事用的助手

后来做了一个给实施和客服同事用的 Agent：上传客户的资料，或者用一句话描述需求，它来帮忙做系统配置、写公式、写表格宏、生成打印模板，甚至生成页面插件。

怎么搭的

用 Vercel AI SDK 搭了一个简易的 Agent Harness：能上传文件，能在沙箱（E2B）里跑代码，能加载 skill，再接上系统的几个工具。各种功能不是一个个单独写的，而是同一个 Harness，配上不同的 skill 和工具。

文件进出沙箱，我用了两个小办法：

• 上传：图片直接交给模型；表格等附件只把链接拼在消息最后，模型觉得需要时，再自己用工具把文件传进沙箱去读。这样不用每次对话都启动沙箱。Anthropic 的代码执行工具是另一种做法：文件引用后自动放进沙箱¹。一个默认放进去，一个让模型按需去取。
• 下载：生成的文件要交给用户，我也做成了一个工具，让 AI 需要时调用。Anthropic 的做法更省事：沙箱里有一个约定好的输出目录，放进去的文件会被自动收走、存起来¹。

回头看，差别在于“契约”写在哪里。他们把“输出目录里的就是要给用户的文件”做成了系统规则；我是在提示词里告诉 AI“要给用户文件就调这个工具”，AI 忘了，文件就到不了用户手里。重要的约定和状态，最好由系统记住，不要交给模型。

写公式：给它查询和校验的工具

写公式这件事，最早只用一段提示词，大概能写一些，但准确率没法保证。放进 Agent 以后换了做法：一份讲各类公式怎么写的 skill，加两个工具：一个查公式支持哪些运算符和参数，一个校验公式是否合法。不合法就报错，Agent 拿到报错自己改，直到通过。

但语法对不等于结果对。要确认公式算出来的是不是客户要的，最好让用户给一组输入，在系统里实际跑一遍，对比输出。

写表格宏：在 skill 里讲清输入和输出

一开始 AI 按固定列号取数，各种出错。我先和它一轮轮对话，磨出一个能跑的版本，再让它根据整段对话把做法整理成 skill。skill 里最关键的是讲清楚两件事：客户的表格一般长什么样、最后要输出成什么样；数据源有哪些表、表头有哪些固定字段。这样 AI 按字段名找列，而不是猜列号。

还有一个教训：很多时候卡住我的不是技术，而是我自己还没理清需求就急着让 AI 写。需求没理清，AI 写得再快也没用。

打印模板和页面插件：没法验证的部分

打印模板是让 AI 在沙箱里用 ExcelJS 生成的，页面插件也是让 AI 写的。两者有同一个问题：AI 看不到最后的效果，打印出来什么样、插件调接口对不对，它都没法自己验证，只能靠人去试。

后来我想过，如果把打印模板改成用 HTML 和 CSS 来定义，AI 就能自己渲染出来看效果，这就是把系统改成“AI 友好”的。

做下来想明白的两件事

第一件：闭环最重要，AI 必须能自己验证。 能在 Harness 里自己检查、自己改的（比如公式语法），就做得好；不能的，就只能靠人。

第二件：技术上它已经很像通用 Agent 了，但真正值钱的不是框架，而是把行业的业务知识写成 skill。框架谁都能搭，业务知识只有做这行的人有。

5. Agent 写转换代码 + 规则拦截：表格导入

工厂的表格千奇百怪。小工厂的表格主要图排版好看、用着方便，比如系统里分成三个字段的东西，他们用斜杠连在一起写。我第一次去客户现场就碰上了：他们的表格和我们的导入格式完全不兼容。客户在一边培训，我在旁边写宏把他的表格转成我们能导入的格式，那一个小时一直在着急。

后来做 AI 导入，就是按这个思路：

• AI 写的是转换代码，不是直接转数据。 读客户的表格，执行转换逻辑，输出系统要的 JSON。
• 提交前用规则拦住。 有些格式规则在 skill 里写了很多遍，AI 还是老转错。后来把规则写死：AI 提交结果时检查一遍，不对就打回并告诉它错在哪，它自己改到通过为止。
• 转换方案沉淀成代码。 同一个客户的表格格式一般不常换，下次直接把这段代码跑一遍，几秒就转好。
• 文本要对应到系统里的数据。 AI 提取出来的只是文本，还要先校验系统里有没有对应的记录，没有的才创建。
• 哪些错系统处理，哪些交给客户。 文本怎么对应到系统数据，这类错系统处理；客户表格本身的问题，比如重复的行，要明明白白提示给客户，让他自己改，而不是悄悄替他合并。我们判断不了那样对不对。

二、现在常说的几种结构

Workflow 和 Agent

Anthropic 在《Building effective agents》里把这类系统分成两种²：

• Workflow（工作流）：步骤由代码定好，模型在固定的位置干活。
• Agent：模型自己决定下一步做什么、调用哪个工具，一直循环到任务完成。

他们的建议是先用最简单的办法，确实需要时再加复杂度。这些都建立在同一块积木上：一个能调用工具、检索资料的模型，文中叫“增强的 LLM”²。上面第 1 种就是只用这块积木、调用一次的最简单情况。

文中列了五种常见的工作流，正好能对上我试过的：

在实际的场景里，两者往往是混着用的：整体是一个 Workflow，中间最难写死的一段交给 Agent。表格导入就是这样：中间读表、写转换代码交给 Agent；Agent 做完后调用一个“提交”工具，这个工具其实就是 Workflow 的下一步。检查通过，Agent 走出自己的循环，进入后面写死的流程；不通过，错误原因返回给它接着改。

这是我自己的做法，后来查了一下别人怎么做，思路差不多：

• HumanLayer 的《12-Factor Agents》观察到，线上跑得好的“AI Agent”，很多其实大部分是写死的代码，只在恰当的地方撒上几步 LLM；它建议自己掌握控制流程，用小而专注的 Agent³。
• Vercel AI SDK 的文档里有现成的写法：给 Agent 一个 done 之类的工具，Agent 一调用它，循环就结束，最终结果从这次调用的参数里取⁴。
• Pydantic AI 默认也是让模型调用一个“输出工具”来交结果；没通过校验，就把错误原因发回给模型，让它重新输出⁵。

所以可以这样理解：Workflow 管整体的顺序和规则，Agent 只负责中间最难写死的一段；把 Workflow 的下一步做成 Agent 的工具，Agent 一调用，就从灵活的部分回到确定的部分。

Agent 由什么组成

现在大家说的 Agent，基本是这几样拼起来的：

• 模型：负责想。这部分由模型公司决定，我们改不了。
• 工具：负责做。查数据、写文件、跑代码、调系统接口，也包括各种搜索和检索。现在多用 MCP 这类统一的接法。常听到的 RAG，其实也是一种检索工具：把资料切成片段，按语义搜出相近的部分交给模型。适合知识还没整理得很细的时候先用起来，但效果不一定特别好。
• 循环和外壳：让模型想一步、做一步、看结果、再想下一步；外壳还管权限、沙箱、出错了怎么办。
• 上下文：每一步喂给模型什么。说明文件、skill、历史记录、工具返回的结果，都在这里。

最近大家讲得最多的是“上下文工程”⁶：模型能力差不多的时候，决定效果的是每一步给它看什么、不给它看什么。上下文不是越多越好。前面识别单据时只放客户常用的选项，就是一个很小的上下文工程。

先想清楚：模型知道什么，不知道什么

给模型准备上下文之前，可以先把它定个位。它像一个刚入职、学历很高的新同事：通识和专业能力都有，但对你们公司一无所知。所以要告诉它的东西分两类。

它知道的，要帮它想起来。 常识、制造业和 ERP 的大致流程、写代码的能力，模型都有。但知道不等于做任务时会想到。把这次任务用得上的那部分点出来，比如“这是一张物料清单，编号的层级表示父件和子件的关系”，它就更容易调出已有的知识。

它不知道的，必须写清楚。 你们的系统能做什么、有哪些模块、字段是什么意思、有哪些规则和限制、一件事该怎么操作，这些模型都不知道。系统是人设计的，每家都不一样。可以按“能做什么、怎么用、有什么规则、哪些做不到”来整理。用什么形式交给模型，写进提示词、做成 skill、还是放进 RAG，都可以。

Skill：拿来就能用的 SOP

Skill 就是一份写好的做法：什么情况用、怎么做、有哪些坑，还可以放写好的脚本直接运行。Agent 平时只知道每份 skill 的名字和简介，遇到相关的任务才去读全文⁷。

它跟人做事的方式很像：新人不会的时候，就去翻 SOP。行业的业务知识，本来也就是一份份 SOP。用文件夹分好类，让 Agent 一层层往下看，用到哪部分读哪部分。一句话：skill 是 SOP，RAG 是搜索工具。

子 Agent

一个任务太大时，主 Agent 把一部分交给子 Agent，子 Agent 在自己的上下文里做完，只把结果交回来。

举个例子：整理录音转录稿里的错别字。100 个文件，一个 Agent 从头改到尾，越往后上下文越乱。分成 10 批交给 10 个子 Agent 同时改，快很多。关键有两点：

• 上下文隔离。 主 Agent 只拿到每批的结果，不会被中间过程塞满，也不会被别的批次带偏⁸。
• 主 Agent 负责把关。 结果交回来后先 review 一遍，有问题再改。

Anthropic 的深度研究功能就是这样做的：一个主 Agent 拆任务，几个子 Agent 并行查资料，再压缩后交回。在他们的内部测试里比单个 Agent 效果好了 90% 左右，代价是 token 大约是普通聊天的 15 倍⁹。

但子 Agent 不是越多越好。子任务之间依赖多、需要共享上下文的，就不适合拆，大多数写代码的任务就是这样⁹。Cognition 说得更直接：子 Agent 看不到彼此的决定，很容易做出互相矛盾的结果¹⁰。所以每批互不相关、可以并行的任务适合拆；前后依赖的，还是交给一个 Agent 一步步做更稳。

怎么做到“确定性输出”

工业场景要求每次都对。我的看法是：

• 让 AI 输出结构化的结果（比如 JSON），而不是直接改系统；
• 能用代码校验的，全部用代码校验，并把校验做成 AI 能调用的工具，让它自己验证、自己改；
• AI 只放在最难标准化的那一步；
• 规则写在提示词里 AI 不一定听，关键的规则要在提交前写死拦截，并告诉 AI 错在哪；
• 能沉淀成代码的就沉淀成代码，下次直接跑；
• 结果先给人确认，再写进系统；
• 出错了要能回滚。

三、记忆：怎么让它越用越准

先说清楚一件事：模型本身不会因为用得多就变聪明。我从 OpenClaw 得到过一个启发：Agent 能改的是自己的身体，而不是自己的脑子；脑子是模型公司决定的，它能改的是自己的记忆。所谓越用越准，其实是给它看的东西越来越准。

这部分我自己也没完全想好，按三个问题来整理。

记什么

LangChain 的记忆库 LangMem 把 Agent 的记忆分成三类¹¹，放到工厂场景里大概是：

• 事实：对这家工厂的了解。常用哪些工序、有哪些产品、表格习惯怎么写。
• 经历：之前做过什么、错在哪、为什么错。
• 做法：Agent 该怎么做事。skill、提示词规则，也包括工具和参数的说明。

放在哪，怎么用

1. 每次都注入系统提示词。 定义一个结构来存记忆，让 Agent 能写进去，每次对话开始时放进上下文。ChatGPT 的记忆就是这类¹²。适合少而稳定的信息。
2. 放进文件系统，按需去取。 记忆存成一个个文件，Agent 做任务前先看目录，用到哪份读哪份，做完再写回去。OpenClaw 是这样做的；Anthropic 给 Claude 的记忆工具也是这个思路¹³。我自己的个人知识库也是：让 Agent 自己记录细节、把踩过的坑记下来。

工厂这种场景信息量很大，我倾向于第二种。都塞进一个提示词，会堆满“遇到这种情况走这条”，让模型多走几步、自己去翻需要的那部分，可能更好。这一点我还不确定。

谁来写，什么时候写

• 人写。 或者 AI 先写、人来改。比如人工修正过的识别结果写回记忆，下次遇到同一家工厂可以参考。
• Agent 做任务时顺手写。 每次遇到问题，把错误和原因记下来，下次先搜有没有记过。马上生效，但 Agent 干活时多了一件事¹¹。
• 事后统一整理。 任务结束后再跑一遍，整理、合并、覆盖旧的。不拖慢速度，但更新慢一些¹¹。

几个要注意的地方：

• 记忆会过时。 据一篇论文的摘要，说明和实际情况冲突时，Agent 九成会照着旧说明做¹⁴。要定期清理，或者规定“和实际情况冲突时以实际为准”。
• AI 自己总结的 skill，通常不如人整理过的好¹⁵。最好是 AI 先写，人来改。
• 记什么，比怎么存更重要¹⁶。
• 大多数“自我进化”其实是记忆，不是学习¹⁷。模型本身没变，变的是给它看的东西。

四、几点自己的看法

• 先验证这件事有没有价值，再决定要不要做成复杂的 Agent。很多问题，一个好的提示词加一份好的知识就够了。
• 技术更新最快，业务知识最稀缺。框架会过时，把行业经验写成 skill 才是能攒下来的东西。
• 能确定的交给代码，不能确定的交给 AI，最后让人确认。
• 分清哪些错系统该处理、哪些该交给客户。
• 让 AI 能自己验证。系统本身做不到的话，就考虑把系统改成“AI 友好”的。
• 别只看准确率，也要看用的人知不知道它能干什么。面对一个空输入框，很多人不知道该问什么；把常见场景做成按钮和表单，打开就能用。

这篇文章是 AI 写的，你完全可以拿 AI 去读。更重要的是，我想记录下我的一些理解，也想分享给大家。