1. 五个行业的五类需求指向同一批能力
把五个行业的五件活摆在桌面上。
制造业的车间主任想让系统读一批零件图纸，问它某个尺寸公差按哪个标准走。零售电商的运营想让它算昨天各品类的销售额，回头看一眼是哪个渠道拖的。政务大厅的工作人员想让它一次查完三个系统的材料，判断这位市民还差哪一份。医院病案室想让它在病历摘要里把用药禁忌标出来，再整理成一份可归档的材料。证券公司的分析岗想在对话里直接出一张同业对比表，不用再导出去做。
五件活看着毫不相干，要求其实指向同一批能力：能读资料再回答；能查数、能算指标；能读写业务系统；能跨系统调接口；能产出成型的文件和表格；能在对话里把结果渲染出来；能写脚本；能操作没有接口的老系统；能把一件事拆成多步、多路一起干；能记住上一轮和上一次；能看图听语音；能自己检查一遍再交。
这十二类能力，没有一类是大模型自带。
2. 装上外壳工程后可承担的 12 类任务
2.1 十二类能力的完整清单
大模型只负责理解和生成。把它自己的能力和外面那一圈东西合起来，才有下面这十二类。
| 能力 | 能干的活 | 案例 |
|---|---|---|
| 读和答 | 基于给定资料回答问题、摘要、翻译、改写、按格式提取 | 制造业：读图纸和工艺卡，答公差按哪个标准走 |
| 查和算 | 把自然语言翻成查询语句，取数、算指标、出图表 | 零售电商：算昨天各品类销售额，拆到渠道 |
| 读写业务系统 | 在系统里查单据、建单、改状态、提交审批 | 制造业：工单建单、改状态、走审批 |
| 调接口和接系统 | 调已有系统的接口取数或写回，按统一协议接工具和数据 | 政务：一次查完三个系统的材料 |
| 产出内容和文件 | 写报告、写方案、生成表格、生成演示文稿 | 医疗：整理成一份可归档的材料 |
| 生成界面 | 在对话里把结果渲染成表格、图表、表单、看板 | 金融：对话里直接出一张同业对比表 |
| 写代码 | 写脚本、改代码、生成前后端页面、做数据处理 | 内部小工具页面快速搭出来 |
| 操作电脑和浏览器 | 像人一样点按钮、填表单、在浏览器里查和提交 | 政务：没有接口的老系统靠它录入 |
| 编排与协作 | 把一件事拆成多步、按条件走分支、多路同时干、多角色分工 | 调研类任务多路检索再汇总 |
| 记忆与个性化 | 记住用户偏好和历史，下次接着用；跨会话保留长期信息 | 客服场景里客户偏好延续 |
| 看和听 | 识别图片、读表格截图、听语音、做实时对话 | 制造：拍设备铭牌和指示灯照片让它认 |
| 自我改进 | 做完先自己检查一遍再交付；按评测结果持续调优 | 问答场景答错回流 |
2.2 十二类能力各自的上限与失效方式
读和答只在它看得见的资料范围内作答，资料里没有的它会编，长文档还容易只看开头。
查和算的口径要靠人给，表结构它不懂业务含义，你问「活跃用户」，它可能按自己的定义算出来一个数。
读写业务系统的风险最高，重复提交、把测试数据写进正式库、改错对象都发生过。
调接口和接系统的上限就是接口本身，接口没有的能力它做不到，接口不稳它跟着不稳。
产出内容和文件要求格式提前定死，事实性内容要有人核，否则一份文档里前后口径能对不上。
生成界面渲染成什么样，由客户端或协议决定，不由模型决定，渲染出来的东西能不能点还是个单独的问题。
写代码能跑通不等于对，上线要走原有研发流程。
操作电脑和浏览器在界面一改就失效，速度比接口调用慢很多，没有接口的老系统才值得用它。
编排与协作的步骤越多越不确定，能一个人干的活就别组队。
记忆与个性化要提前定好记什么、记多久、谁能看。
看和听的识别精度受图像质量和口音影响，识别错一次会把后面的判断全带偏。
自我改进能减少明显错误，但保证不了对。
3. 外壳工程八件的分工与依赖
给模型装上这一圈东西之后，外层就有八件。它们在上一份材料里出现过，这一份把它们的相互关系讲清楚。
3.1 外壳工程八件的职责
| 部件 | 它管什么 |
|---|---|
| 提示词（Prompt） | 交给模型的那套规矩和任务说明 |
| 上下文（Context） | 这一轮模型实际能看到的内容 |
| 记忆（Memory） | 跨轮次、跨会话留下来的内容 |
| 技能（Skills） | 写下来、能反复用的一套做法 |
| 工具与协议（Tools & MCP） | 去碰外部系统的那只手 |
| 知识库（Knowledge Base） | 需要现查的那批资料 |
| 编排（Orchestration） | 谁先谁后、失败了怎么办 |
| 运行环境（Runtime） | 它在哪跑、能碰到什么 |
3.2 八件之间的先后关系与依赖关系
提示词排在最前面。模型每次收到的东西里，最先定调的就是它：任务是什么、口吻什么样、什么情况该交给人。提示词没写对，后面配再多东西也救不回来。
上下文是每一轮的现场。提示词、记忆里取出来的内容、知识库检索回来的段落、用户这一轮说的话，全都要装进上下文，模型才看得见。上下文装不下的时候，装进去的东西要按重要性挑，这个取舍是产品经理能拍板的。
记忆和知识库解决的是两件不同的事。记忆留的是「这个人、这次任务」的过程，知识库查的是「这家单位的成文资料」，两者的更新节奏和权限规则都不一样。
技能和工具解决的是另外两件事。工具是那只手，负责去碰外部系统；技能是那套手法，负责把一套做法写下来反复用。同一件活，技能告诉它按哪几步做，工具负责真的去调用。
编排管的是多步之间的顺序和失败处理。一件事要跑五步，中间第三步失败了是重试、跳过还是停下来问人，写在编排里。
运行环境兜底。它跑在哪台机器、能碰到哪些数据、出事怎么退回来，都由这一件定。前面七件配置得再好，运行环境没设边界，一次误操作就能捅出大娄子。
4. 智能体的四类设计模式
八件配齐之后，它办事的套路就是那几套。行业内把它归成四类做法。
4.1 反思、工具使用、规划、多智能体
反思（Reflection）：先写一版，再回头挑自己的毛病，改一版。适合有明确好坏的活，比如一份摘要写得全不全、一份材料的口径对不对。
工具使用（Tool Use）：该查的去查、该算的去算，不靠自己回忆。适合需要准确数字和最新状态的活。
规划（Planning）：先想清楚要几步，再一步步做。适合步骤多、中途容易走岔的活。
多智能体（Multi-agent）：把活拆给几个角色，或者几个一样的分身同时干。适合一个人干太慢、或者需要不同视角的活。
四类做法可以叠着用。一份调研报告的做法常常是：先规划分几块，每块调工具去查，几路同时干，最后反思一遍再成稿。
4.2 两类执行方式：逐步推理与先规划后执行
规划这条路往下走，又分成两派。
一派叫想一步做一步，业内叫 ReAct（Reasoning and Acting）：每一轮先想、再动手、看到结果再想下一步。它灵活，上一步结果一变，下一步跟着变。
另一派叫先列计划再执行，简称 Plan-and-Execute：开工前把整条计划列出来，然后按计划一步步走，中途可以回来改计划。
两派没有高下，看活的性质。步骤能列清、中途不容易被打断的活，先列计划更稳；情况随时在变、每一步都依赖上一步结果的活，想一步做一步更合适。
两件活，一件边做边看一件先列计划
想一步做一步 · 政务一次查完三个系统的材料
- 第 1 轮调社保接口，返回参保状态
- 第 2 轮看到参保状态这一栏断了，改调医保接口核对
- 第 3 轮拿两份结果判断还差哪一份材料
- 第 4 轮决定再查不动产登记，因为缺的这一项跟住房证明相关
上一步返回什么，决定下一步查哪儿。
先列计划再执行 · 零售电商算昨天的销售额
- 开工前列的四步取昨日订单明细、按品类汇总、拆分到渠道、生成对比表
- 执行到第三步发现两个渠道名对不上，回到第二步改一次映射
- 改计划这件事本身记在过程里，第四步用的是改过之后的映射
中途只动一处计划，剩下的照着往下走。
两条路没有高下，看活的性质。
5. 智能体自我改进的四个循环
5.1 四类自我改进的循环
行业里讲自我改进，说的是四个循环。
一是在自己的循环里边干边学。做完一步先自己评一遍，不行就改，改完再评。这个循环最快，也最浅。
二是把经验沉淀成技能包。同一套做法跑通几次之后，把它写成技能存下来，下次直接调用，不用重新交代。
三是把经验在多个智能体之间共享。一个智能体踩过的坑，写成一份能传递的记录，别的智能体也能用上。
四是直接改参数或者改代码。这条最深，也最危险，改了会同时影响所有用到它的场景。
5.2 自我改进环节，产品经理盯什么
第一件，评估器比生成器更重要。它自己评自己，评得好不好取决于那把尺子刻得准不准。尺子从哪来、谁定、多久校准一次，比它自己写得漂不漂亮重要得多。
第二件，能回滚是前提。只要允许它改技能、改参数、改代码，就得有一条退回去的路，并且写清退回上一版要多久。没有回滚能力就别开这个口子。
第三件，共享来的技能要有人管。一个智能体写出来的技能被别处用了，出了事找谁，这条要落到人头上。
6. 智能体平台分两类
6.1 智能体平台的两类形态
大模型和外壳工程这一整套，今天不用从零写。市面上有现成的东西，分两类。
| 类别 | 代表 | 谁在用 |
|---|---|---|
| 编程与通用工作类 | Codex、Claude、WorkBuddy、Pi、DeepSeek Harness | 工程师、写代码和分析的人直接上手用 |
| 应用搭建类 | Coze、Dify、n8n、FastGPT、MaxKB、RAGFlow | 业务侧和产品经理拖拽搭应用 |
这两类不是一回事。第一类是拿着现成的智能体干活，你提要求、它交付；第二类是拿它搭出你自己单位的应用，交付物是一套能给别人用的东西。做 AI 产品经理，日常打交道更多的是第二类。
6.2 代码框架和低代码平台的分界
应用搭建类里面，还要再分一层。
一层是拖拽搭起来的低代码平台，像 Coze、Dify、n8n、FastGPT。它们的强项是把常见的那几件事做成了现成组件：接模型、配提示词、挂知识库、接工具、画流程，点几下就能跑起来。
另一层是写代码用的框架，像 LangGraph、AutoGen、AgentScope、CAMEL。它们的强项是处理平台组件盖不住的复杂度：流程里有大量自定义判断、状态要在多轮之间精确保存、要和单位已有的系统深度咬合。
分界线可以这么画：拖拽平台能把八件都配齐的活，就在平台上搭；一旦出现「这个判断只有我们的业务规则能算」「这个状态要在几个系统之间来回传」，就该拉研发上框架。
7. 评估一个智能体平台的七个维度
拿到一个没见过的平台，不用逐个功能点翻。看它有没有这七块就够了：模型接入、提示词、知识库、工具、编排、权限、评测。
前五块决定它能不能把活干起来，后两块决定它能不能上线。缺权限那一块的平台，多部门共用时管不住；缺评测那一块的平台，效果好不好只能靠感觉。
拿到一个没见过的平台，七块挨个对一遍
七块和各管什么
- 模型接入接的是哪几家模型、怎么计费
- 提示词系统提示词放在哪、能不能分版本
- 知识库资料怎么入库和怎么检索
- 工具能接哪些系统、写权限开不开
- 编排多个步骤怎么串、怎么分支
- 权限谁能用、能碰哪些数据
- 评测用哪批题、多久回归一次
前五块决定它能不能把活干起来，后两块决定它能不能上线。
勾到哪一步，能走到哪一档
- 只勾上前三块能答问题，做不了多步的活
- 再勾上工具和编排能把活干起来，但还上不了线
- 再勾上权限和评测七块齐了，可以进入上线评审
- 单独把权限退掉多部门共用时管不住，只能先在一个部门里试
缺得太多只能跑个演示，七块齐了才进上线评审。
前五块决定它能不能把活干起来，后两块决定它能不能上线。
8. 动手搭之前，先自查一遍
8.1 六个问题答完再动手
- 这七块它有哪几块？缺的那一块会不会成为上线时的拦路石？
- 十二类能力里，这个场景真正用得上的是哪几类？用不上的别配。
- 每类能力的天花板在哪？场景正好压在天花板上的，风险要提前说。
- 这活是能一个人干，还是必须分工？分工能省时间还是会互相等。
- 它会不会自己改技能、改参数？开了这个口子，回滚的路在哪。
- 评估这件事谁负责、尺子从哪来？
8.2 搭建智能体应用时的三个常见误解
一个是把这一集当成平台测评。这一集给的是判断工具，具体哪家好用要放到自己单位的场景里试，不能拿别人的结论当答案。
一个是以为零件配得越多越好。八件里用不上三件是常事，多配一件就多一个要维护、要监控、要出问题时找人负责的东西。
还有一个是跳过能力边界直接上手搭。十二类能力每一类都有自己的失效方式，先把「这类活最容易在哪翻车」想清楚，再谈怎么搭，返工次数会少很多。
9. 一份需求要哪几类能力，看完能点名
一件事是认出能力。拿到一份需求，能说出它要的是这十二类里的哪几类，其余的不必配。
二件事是看懂平台。打开任何一个智能体平台，知道该看哪七块，能当场判断它够不够上线。
这一份要交出的是判断路线。这活该在拖拽平台上搭，还是必须拉研发上框架，能给出理由而不是感觉。
下一份材料从上下文、记忆与提示词讲起。这三件是外壳工程里最好上手、也最直接影响答得准不准的一块，先把它们讲透，再往后进技能和工具。