课外阅读 一章看懂 AI 工作系统

先看全景：一次 AI 任务里发生了什么

1. 用户提出目标与资料
2. Agent 规划：拆解成几步
3. LLM 负责理解与生成；Skill 提供专业方法与脚本；工具/连接器经 MCP 或 API 触达文件、知识库与业务系统
4. 中间结果汇总回模型，模型判断下一步
5. 检查点与验收（人负责边界与验收）
6. 最终产物

这张图可以用一句话解释：模型负责理解和生成，Agent 负责围绕目标组织行动，Skill 提供专业方法，工具与 MCP/API 让行动触达真实世界，人负责边界与验收。

五类角色里，模型是大脑，Agent 是调度员，Skill 是专家手册，工具与接口是手脚，人是裁判。下面每一节就是把其中一个角色讲清楚，顺便标出它能和不能的边界。

LLM：会根据上下文预测内容的基础模型

LLM 是 Large Language Model，大语言模型。它从大量数据中学习语言和知识模式，根据当前输入生成最可能的后续内容。它本质上是个「预测下一个内容」的引擎——不是数据库，也不是会替你负责的人。

它擅长什么

• 理解、归纳和改写文本
• 从材料中提取结构
• 生成草稿、方案和代码
• 根据示例模仿格式和风格
• 在工具返回结果后继续分析

它不天然保证什么

• 不保证每个事实都正确
• 不知道企业最新内部状态，除非提供资料或连接系统
• 不会因为语言自信就拥有真实证据
• 不自动拥有文件、账号、数据库和网络权限
• 不承担业务和法律责任

为什么会「幻觉」

模型的目标是生成连贯内容，不是内置事实数据库。当资料缺失、问题含糊或要求它给出确定答案时，它可能用合理但不真实的内容填补空白。这不是 bug，是「按概率补全」这件事的副作用。理解了这点，你就不会再追问「它明明说得很肯定，为什么是错的」——肯定和正确是两件事。

降低幻觉的办法

• 提供可靠资料
• 要求引用位置（说清楚结论来自哪段材料）
• 允许回答「无法确认」
• 把事实提取与建议生成分开
• 对高影响结论人工复核

Token 与上下文窗口：模型眼前能看到多少

Token 是模型处理文本的基本单位，不完全等于字数。中文里一个字可能对应一个或几个 Token，代码和标点也单独计费。上下文窗口是一次推理中模型能够处理的输入、历史对话和输出总量。把 Token 想成模型的短期记忆容量：装得下才看得见，装不下就得丢或压缩。

上下文变长不一定更好

把所有文件和几个月对话都塞进一个任务，可能导致：旧要求与新要求冲突；关键资料被大量无关内容淹没；成本和等待时间增加；模型引用了过期版本。窗口越大，越容易「水漫金山」——重要的反而被冲淡。

更稳妥的做法

按项目整理「当前规则、已确认事实、决策记录和本次输入」，长项目使用文件和项目记忆，而不是依赖无限对话。简单说：别把所有聊天记录当数据库用，该落盘的落盘，该分项目的分开。

Prompt：任务说明，不是神秘咒语

Prompt 是给模型或 Agent 的输入，包括目标、背景、资料、约束、示例和输出要求。好的 Prompt 不以长度取胜，而以信息是否足够执行和验收取胜。写 Prompt 不是在「念咒」，是在写一份能交给同事执行的任务单。

六要素里最容易被忽略的是「验收」：没有验收标准，模型只能按自己的理解交差，你也就没法说它错在哪。

Prompt、任务卡与 SOP

• Prompt：本次怎么说
• 任务卡：同类任务可以填写的结构
• SOP：固定步骤、角色、检查点和异常处理
• Skill：把稳定 SOP、脚本和资源封装成可执行能力

四者是从「一次性说明」到「可复用能力」的逐级固化。不是每个 Prompt 都值得变成 Skill。先重复成功，再逐步固化：一个只做过一次的任务，先写好 Prompt 跑通；跑顺三五次、模式稳定了，再考虑沉淀成 Skill。

Agent：能围绕目标循环行动的执行体

Agent 不只是「回答一次」，而是持续执行一个循环：理解目标、观察环境、决定下一步、调用工具、读取结果、修正计划，直到交付或触发停止条件。

1. 接收目标
2. 观察资料与状态
3. 规划下一步
4. 调用工具执行
5. 读取结果与错误
6. 未完成 → 回到“观察资料与状态”继续；应暂停 → 请求人工确认；完成 → 交付并验收

关键差异在最后一行：聊天模型说错了，最多误导你；Agent 做错了，可能真的删了文件、发了邮件、改了数据库。所以 Agent 需要的不是更聪明的提示，而是更硬的护栏。

Agent 的停止条件

好的 Agent 不应「永远想办法继续」。出现以下情况，应暂停并请求人处理：

• 关键输入缺失
• 目标冲突
• 权限不足
• 成本超预算
• 动作不可逆
• 结果无法验收

知道什么时候停下来问人，比什么都自己硬扛更专业。一个不会停的 Agent，比一个笨 Agent 更危险。

Tool：让 Agent 真的能做事

Tool 是 Agent 可以调用的具体能力，例如读取文件、执行搜索、生成表格或发送消息。Connector（连接器）通常是产品已经封装好的第三方服务连接，强调授权后直接使用。

每个工具要问五件事

1. 使用谁的身份
2. 能读取什么
3. 能修改什么
4. 数据会发到哪里
5. 失败后如何停止和回退

Skill：可复用的专业工作方法

Skill 不是更聪明的模型，而是把某类任务需要的说明、脚本、知识和模板组织起来，让 Agent 更稳定地完成动作。它的价值不在「让模型变强」，而在「把容易做错、容易遗漏的环节固定下来」。同样的发票处理，让模型每次现写，十次可能有三种写法；写成 Skill，十次走同一条被验证过的路。

invoice-skill/
├── SKILL.md          # 触发条件、步骤、边界与输出
├── references/       # 字段、分类和业务规则
├── scripts/          # OCR、校验、表格处理
├── templates/        # Excel 和报告模板
└── tests/            # 正常与异常样例

SKILL.md 是入口，告诉 Agent「什么时候用我、怎么用、边界在哪」；references 放业务知识；scripts 放真正执行的代码；templates 保证输出格式一致；tests 保证异常情况也被覆盖。

Prompt 往往只影响本次对话；Skill 可以被不同任务调用，并能携带脚本、资源和稳定流程。但 Skill 仍可能出错，也可能请求本地、网络或第三方权限。记住：Skill 是「方法封装」，不是「能力保证」。

安装第三方 Skill 的风险

• 读取不必要的本地目录
• 外发输入材料
• 获取 API Key 或账号
• 执行系统命令
• 包含恶意提示或代码
• 依赖过期、无人维护

因此应检查来源、代码、权限、网络、凭证、成本和停用方法，并先在隔离目录测试。第三方 Skill 和装浏览器插件一个道理：方便，但要先看它要什么权限。

MCP：让 AI 接入工具与数据的标准接口

MCP 是 Model Context Protocol。它规定 AI 客户端如何发现和调用外部工具、读取资源或获取提示模板。把 MCP 想成「AI 世界的 USB 接口」：工具提供方按一套标准暴露能力，AI 客户端按同一套标准去用，不用每家重新适配。

MCP 解决什么 / 不解决什么

没有 MCP 时，接一个 CRM 要写一套适配，接一个数据库又写一套；有了 MCP，工具方一次性按标准暴露，所有支持 MCP 的客户端都能直接用。但 MCP：

• 不自动判断数据是否合规
• 不替你保管好所有密钥
• 不保证工具结果正确
• 不自动实现身份与最小权限
• 不等于连接后可以开放生产写入

一句话：MCP 解决的是「怎么连」，不解决「连了之后安不安全、对不对」。安全那层仍然是你的责任。

用户级与项目级

用户级适合多个项目复用的公共能力；项目级适合客户、数据库或业务专属工具。敏感连接优先项目隔离，避免跨项目误调用——比如公司的生产数据库，只该在对应项目里接，别放成全局用户级，否则另一个无关任务也可能摸到它。

API 与 MCP 的关系

API 是软件之间交互的接口，例如通过 HTTP 查询数据或创建记录。MCP Server 可以在内部调用一个或多个 API，再以 Agent 更容易使用的方式暴露工具。一句话：API 是地基，MCP 是在地基上盖的、Agent 能直接进出的门。

• 直接使用 API 更灵活，但需要理解认证、参数、错误和限流
• 使用成熟 MCP 更方便，但仍要审查它封装了什么请求和权限

方便不等于免审。MCP 帮你省了适配活，但「它背后到底调了什么 API、用了什么权限」你得心里有数。

知识库、RAG 与记忆

这三者都和「AI 依据什么」有关，但保存的东西和失效方式完全不同。

知识库

保存可检索的制度、产品、案例、SOP 等资料。它是外部的资料室，模型用时才去翻，翻完不保证下次还记。

RAG

Retrieval-Augmented Generation，检索增强生成：先从资料库找到相关片段，再把片段提供给模型回答。它是一根链条——资料差、切得烂、检索偏，回答就跟着歪；引用机制很重要。

记忆

保存偏好、长期规则、项目决策或历史状态。最危险的是「它自己不会发现过期」——一条半年前的错误规则，会被 Agent 当真理反复用。重要信息要有来源、日期、负责人和更新机制。

一句话区分：上下文是这次聊天的短期记忆，知识库是随时可查的资料室，记忆是跨任务保留的长期设定。

Workflow 与 Agent 的区别

Workflow

标准化的生产线：步骤在设计时就定好，按顺序或分支执行。像一份写了「第一步做 A，第二步做 B，B 通过后做 C 否则做 D」的 SOP。

Agent

会思考、能自己拿主意的执行者：只给目标，运行时自己决定下一步。像你雇的一个人，你只说「把这批发票处理完」，他中途自己判断要先查哪张、卡住了问你。

核心区别是决策权在哪：Workflow 的每一步「走哪条路」在设计阶段就固定了；Agent 的下一步由模型在执行阶段根据环境实时决定。其他差别都从这儿长出来。

常见误区

• 「Agent 一定比 Workflow 强」：不对。确定任务用 Workflow 更稳更省，硬上 Agent 反而容易跑偏、难审计、成本高。
• 「Workflow 不能含智能」：错。Workflow 的节点完全可以调用模型做摘要、分类、抽取，只是「走哪条路」仍由流程定。
• 「Agent 全自动就最好」：过度放权会让失败更难定位。真复杂的系统，往往是 Agent 在高层决策，把稳定环节交给 Workflow。

两者如何协同

• Agent 内含 Workflow：Agent 把已经稳定的子任务写成固定流程（比如一个 Skill 背后就是 Workflow），只在不确定处自己判断
• Workflow 节点调 Agent：生产线上某个判断节点，交给一个 Agent 处理非结构化输入