课外阅读：一章看懂 AI 工作系统
这一章留给愿意多懂一点的读者：不求成为工程师，只求在 buddyme 出现"新名词"时，心里不再打怵。
十一节短文，每一节讲清一个概念——它们合起来，就是一次 AI 任务背后的完整图景。
前面 28 章讲的都是「用 buddyme 干具体活」，这一章往后退一步，回答两个更根本的问题：它凭什么好用，以及怎么用才一直好用。搞懂原理不是为了当工程师，而是为了在它跑偏的时候你知道为什么、在它费点数的时候你知道省在哪里。
- 大模型是怎么「思考」的——Token、上下文窗口、温度与采样，决定了它为什么有时聪明有时糊涂；
- 指令五要素与迭代追问——同一件事，说法不同，产出质量差一倍；
- 模型为什么跑偏——问题分四类，每类有一套对应的纠偏方法；
- 技能与 Agent 的运行机制——理解了它怎么干活，你才能让它替你设计活儿；
- 自动化工作流与成本控制——让定时任务靠得住，让每一分点数花在刀刃上。
不需要任何编程基础，每一节都从「这对你用 buddyme 意味着什么」讲起。读完这一章，你再看前面 28 章的很多操作，会有「原来如此」的感觉。
先看全景：一次 AI 任务里发生了什么
用户目标与资料 → Agent 规划 Agent 规划 → LLM 理解与生成 Agent 规划 → Skill 方法与脚本 Agent 规划 → Tool / Connector Tool / Connector → MCP / API MCP / API → 文件、知识库与业务系统 LLM 理解与生成 → 中间结果 Skill 方法与脚本 → 中间结果 文件、知识库与业务系统 → 中间结果 中间结果 → 检查点与验收 检查点与验收 → 最终产物
这张图可以用一句话解释：模型负责理解和生成，Agent 负责围绕目标组织行动，Skill 提供专业方法，工具与 MCP/API 让行动触达真实世界，人负责边界与验收。
把一次真实任务拆开看，信息大致这样流动：
- 你提出一个目标；
- Agent 把它拆成几步；
- 遇到专业子任务就加载对应的 Skill，遇到要碰外部系统就调用工具；
- 工具通过 MCP 或 API 真正读写数据库、发消息、改文件；
- 结果回到模型，模型判断下一步；
- 你做边界把控和最终验收。
LLM：会根据上下文预测内容的基础模型
LLM 是 Large Language Model，大语言模型。它从大量数据中学习语言和知识的模式，根据当前输入生成最可能的后续内容。
它本质上是个「预测下一个内容」的引擎——不是数据库，也不是会替你负责的人。认识这一点，是与它良好协作的起点。
它擅长什么
- 理解、归纳和改写文本；
- 从材料中提取结构；
- 生成草稿、方案和代码；
- 根据示例模仿格式和风格；
- 在工具返回结果后继续分析。
它不天然保证什么
- 不保证每个事实都正确；
- 不知道企业最新内部状态，除非你提供资料或连接系统；
- 不会因为语言自信就拥有真实证据；
- 不自动拥有文件、账号、数据库和网络权限；
- 不承担业务和法律责任。
为什么会「幻觉」
模型的目标是生成连贯内容，不是内置事实数据库。当资料缺失、问题含糊或要求它给出确定答案时，它可能用合理但不真实的内容填补空白。
这不是 bug，是「按概率补全」这件事的副作用。理解了这点，你就不会再追问「它明明说得很肯定，为什么是错的」——肯定和正确，是两件事。
降低幻觉的办法
- 提供可靠资料；
- 要求引用位置（说清楚结论来自哪段材料）；
- 允许回答「无法确认」；
- 把事实提取与建议生成分开；
- 对高影响结论人工复核。
Token 与上下文窗口：模型眼前能看到多少
Token 是模型处理文本的基本单位，不完全等于字数。中文里一个字可能对应一个或几个 Token，代码和标点也单独计费。上下文窗口则是一次推理中模型能够处理的输入、历史对话和输出总量。
把 Token 想成模型的短期记忆容量：装得下才看得见，装不下就得丢或压缩。
上下文变长不一定更好
把所有文件和几个月的对话都塞进一个任务，可能导致：
- 旧要求与新要求冲突；
- 关键资料被大量无关内容淹没；
- 成本和等待时间增加；
- 模型引用了过期版本。
窗口越大，越容易「水漫金山」——重要的反而被冲淡。
更稳妥的做法
按项目整理「当前规则、已确认事实、决策记录和本次输入」，长项目使用文件和项目记忆，而不是依赖无限对话。
Prompt：任务说明，不是神秘咒语
Prompt 是给模型或 Agent 的输入，包括目标、背景、资料、约束、示例和输出要求。好的 Prompt 不以长度取胜，而以信息是否足够执行和验收取胜。
写 Prompt 不是在「念咒」，而是在写一份能交给同事执行的任务单。
六要素
| 要素 | 要回答的问题 |
|---|---|
| 目标 | 最终解决什么问题 |
| 输入 | 使用哪些资料或系统 |
| 动作 | 分析、整理、生成还是写入 |
| 约束 | 不能做什么，采用什么规则 |
| 输出 | 交付什么文件或结构 |
| 验收 | 怎样判断正确和可用 |
六要素里最容易被忽略的是「验收」：没有验收标准，模型只能按自己的理解交差，你也就没法说它错在哪。
Prompt、任务卡与 SOP
- Prompt：本次怎么说；
- 任务卡：同类任务可以填写的结构；
- SOP：固定步骤、角色、检查点和异常处理；
- Skill：把稳定 SOP、脚本和资源封装成可执行能力。
四者是从「一次性说明」到「可复用能力」的逐级固化。
Agent：能围绕目标循环行动的执行体
Agent 不只是「回答一次」，而是持续执行一个循环：理解目标、观察环境、决定下一步、调用工具、读取结果、修正计划，直到交付或触发停止条件。
接收目标 → 观察资料与状态 观察资料与状态 → 规划下一步 规划下一步 → 调用工具执行 调用工具执行 → 读取结果与错误 读取结果与错误 → 完成或应暂停？ 完成或应暂停？ —继续→ 观察资料与状态 完成或应暂停？ —暂停→ 请求人工确认 完成或应暂停？ —完成→ 交付并验收
聊天模型是「你问一句它答一句」；Agent 是「你给目标，它自己一步步推进，中途还会看结果、改路线」。
Agent 与聊天模型的区别
| 维度 | 聊天模型 | Agent |
|---|---|---|
| 核心动作 | 生成回答 | 规划、调用工具、执行和交付 |
| 工作对象 | 当前对话 | 文件、工具、系统和任务状态 |
| 过程 | 通常一次生成 | 多轮观察与行动 |
| 风险 | 内容错误 | 内容错误 + 真实操作影响 |
| 控制 | 提示与复核 | 权限、检查点、日志和回滚 |
关键差异在最后一行：聊天模型说错了，最多误导你；Agent 做错了，可能真的删了文件、发了邮件、改了数据库。所以 Agent 需要的不是更聪明的提示，而是更硬的护栏。
Agent 的停止条件
好的 Agent 不应「永远想办法继续」。出现以下情况，应暂停并请求人处理：
- 关键输入缺失；
- 目标冲突；
- 权限不足；
- 成本超预算；
- 动作不可逆；
- 结果无法验收。
Tool：让 Agent 真的能做事
Tool 是 Agent 可以调用的具体能力，例如读取文件、执行搜索、生成表格或发送消息。Connector 通常是产品已经封装好的第三方服务连接，强调授权后直接使用。
模型「知道」不等于模型「能做」
模型可以解释「如何发送邮件」，但只有获得邮件工具和账号权限后，才能实际创建草稿或发送；模型可以写 SQL，但只有数据库工具、网络和账号允许时，才能真正查询。
这点是普通用户最容易误解的：模型「懂」一件事，不代表它「能」做这件事。能不能做，取决于有没有对应的工具、权限和连接。任务失败时，先问「工具通没通、权限给没给」，而不是「模型是不是不行」。
每个工具要问五件事
- 使用谁的身份；
- 能读取什么；
- 能修改什么；
- 数据会发到哪里；
- 失败后如何停止和回退。
Skill：可复用的专业工作方法
Skill 不是更聪明的模型，而是把某类任务需要的说明、脚本、知识和模板组织起来，让 Agent 更稳定地完成动作。
Skill 的价值不在「让模型变强」，而在「把容易做错、容易遗漏的环节固定下来」。同样的发票处理，让模型每次现写，十次可能有三种写法；写成 Skill，十次走同一条被验证过的路。
一个 Skill 可能包含
invoice-skill/
├── SKILL.md # 触发条件、步骤、边界与输出
├── references/ # 字段、分类和业务规则
├── scripts/ # OCR、校验、表格处理
├── templates/ # Excel 和报告模板
└── tests/ # 正常与异常样例SKILL.md 是入口，告诉 Agent「什么时候用我、怎么用、边界在哪」；references 放业务知识；scripts 放真正执行的代码；templates 保证输出格式一致；tests 保证异常情况也被覆盖。
Skill 与 Prompt 的区别
Prompt 往往只影响本次对话；Skill 可以被不同任务调用，并能携带脚本、资源和稳定流程。但 Skill 仍可能出错，也可能请求本地、网络或第三方权限。
安装第三方 Skill 的风险
- 读取不必要的本地目录；
- 外发输入材料；
- 获取 API Key 或账号；
- 执行系统命令；
- 包含恶意提示或代码；
- 依赖过期、无人维护。
因此应检查来源、代码、权限、网络、凭证、成本和停用方法，并先在隔离目录测试。第三方 Skill 和装浏览器插件一个道理：方便，但要先看它要什么权限。
知识库、RAG 与记忆
这三者都和「AI 依据什么」有关，但保存的东西和失效方式完全不同。
知识库
保存可检索的制度、产品、案例、SOP 和其他资料。它解决「AI 依据什么」，但不等于 AI 永远记住一切。
知识库是外部的资料室——模型用时才去翻，翻完不保证下次还记得。
RAG
RAG 是 Retrieval-Augmented Generation，检索增强生成。系统先从资料库找到相关片段，再把片段提供给模型回答。效果取决于资料质量、分段、元数据、检索和引用。
RAG 不是「接了知识库就聪明」，它是一根链条：资料差、切得烂、检索偏，回答就跟着歪。引用机制很重要——能指出结论来自哪段，你才能判断信不信。
记忆
记忆用于保存偏好、长期规则、项目决策或历史状态。错误记忆会被反复放大，因此重要信息要有来源、日期、负责人和更新机制。
记忆最危险的地方是「它自己不会发现过期」——一条半年前的错误规则，会被 Agent 当真理反复用。
三者的区别
| 概念 | 保存什么 | 主要风险 |
|---|---|---|
| 对话上下文 | 当前任务交流 | 太长、冲突、过期 |
| 知识库 / RAG | 可检索事实与资料 | 来源差、版本旧、检索不到 |
| 记忆 | 偏好、长期规则、项目状态 | 错误被长期沿用 |
Workflow 与 Agent 的区别
前面把 Agent 讲清楚了，但还有一个常被混用的词：Workflow（工作流）。它和 Agent 不是替代关系，而是两种「组织行动」的思路。
一句话区分
- Workflow 是标准化的生产线：步骤在设计时就定好，按顺序或分支执行；
- Agent 是会思考、能自己拿主意的执行者：只给目标，运行时自己决定下一步怎么走。
打个比方：Workflow 像一份写好「第一步做 A，第二步做 B，B 通过后做 C 否则做 D」的 SOP；Agent 像你雇的一位伙伴，你只说「把这批发票处理完」，他中途自己判断要先查哪张、卡住了问你。
核心区别：决策权在哪
Workflow 的每一步「走哪条路」在设计阶段就固定了；Agent 的下一步由模型在执行阶段根据环境实时决定。这是两者最本质的差别，其他差别都从这里长出来。
对比表
| 维度 | Workflow（工作流） | Agent（智能体） |
|---|---|---|
| 一句话 | 标准化的生产线 | 会思考、能自己拿主意的执行者 |
| 路径是否预设 | 是，步骤在设计时定好 | 否，运行时根据环境决定 |
| 决策时机 | 设计阶段固定 | 执行阶段动态 |
| 谁来选下一步 | 流程定义 | 模型自己 |
| 可控性 | 高，容易预测和回滚 | 较低，路径可能变化 |
| 调试难度 | 低，步骤清晰可追 | 高，需看日志和中间状态 |
| 适用场景 | 步骤明确、可重复、合规要求高 | 路径不确定、需环境反馈、开放目标 |
| 典型失败 | 卡在某步、分支没覆盖 | 跑偏、无限循环、越权操作 |
| 与 LLM 关系 | 管道里可嵌入模型，但控制流是人定的 | 模型驱动控制流 |
什么时候用 Workflow
- 固定 SOP，比如「收到工单 → 分类 → 派给对应人」；
- 批量处理，比如「把 100 张图统一压缩加水印」；
- 合规审批，每一步都要留痕、可审计；
- 可重复的报表生成。
这些任务路径清楚，用 Workflow 更稳、更便宜、更好查。
什么时候用 Agent
- 目标清楚但路径不清，比如「调研竞品并出对比报告」；
- 需要多工具探索、中途看结果再决定；
- 环境会变，需要边做边调整；
- 开放性强、难以写成固定步骤的任务。
常见误区
- 「Agent 一定比 Workflow 强」：不对。确定任务用 Workflow 更稳更省，硬上 Agent 反而容易跑偏、难审计、成本高。
- 「Workflow 不能含智能」：错。Workflow 的节点完全可以调用模型做摘要、分类、抽取，只是「走哪条路」仍由流程定。
- 「Agent 全自动就最好」：过度放权会让失败更难定位。真正成熟的系统，往往是 Agent 在高层决策，把稳定环节交给 Workflow。
两者如何协同
不是二选一，而是嵌套使用：
- Agent 内含 Workflow：Agent 把已经稳定的子任务写成固定流程（比如一个 Skill 背后就是 Workflow），只在不确定处自己判断；
- Workflow 节点调 Agent：生产线上某个判断节点，交给一个 Agent 处理非结构化输入。
大模型是怎么思考的：写给使用者的原理课
很多人用 buddyme 用了很久，仍然把它当成一个「会聊天的搜索引擎」——丢一句话过去，收一坨字回来，好坏全凭运气。这一节我们反过来，先花十几分钟搞懂 buddyme 背后的大模型是怎么「想」的。原理不用记公式，但每一条都会直接影响你每天的使用方式：为什么它偶尔会「失忆」、为什么长文档中间的要求会被漏掉、为什么同一句话有时写出来天差地别。懂了这些，你才知道该往哪儿使劲。
原理一：Token——模型眼里的世界是「字块」拼成的
这是什么原理：模型不能直接读文字。你发进去的每一句话，都会先被切成一个个小片段，每个片段叫一个 Token，再变成数字给模型算。常见词一个词就是一个 Token，生僻词会被拆成几块。中文比较吃亏：同样一份内容，中文版通常比英文版多消耗 30%-50% 的 Token；代码和带符号的文本也不省。
原理二：上下文窗口——模型的「临时记忆桌面」
这是什么原理：模型一次能「看在眼里」的内容总量是有硬上限的，这个上限就是上下文窗口，里面装着三样东西：你的指令、历史对话、附加的文档材料，还有它正在写给你的回复。注意一个关键事实：模型本身是无状态的——它不会「记住」你，只是每次都把之前所有内容重新打包读一遍。当累计内容超过窗口上限，最早的部分会被截掉，这就是多轮长对话里模型突然「失忆」的原因：不是忘了，是压根看不到了。
怎么做（用好这条原理）：
- 第 1 步：一个对话窗口只干一类事。谈完合同就关掉，写周报另开新窗口，别让两摊事互相搅。
- 第 2 步：长对话过半时，让它先总结一下：「请总结我们目前确认的需求和待讨论的问题」，然后以总结为起点继续，等于把桌面收拾干净再干活。
- 第 3 步：关键结论别只说一遍。重要约束在后面几轮里再强调一次，防止它被截掉。
原理三：Lost in the Middle——模型会「忽略中间的话」
这是什么原理：斯坦福大学 2023 年的研究发现，当输入内容超过大约 2000 个 Token 时，模型对开头和结尾的信息最敏感，夹在长文中间的信息容易被系统性忽视。这不是 bug，是注意力机制的天性。
原理四：逐字生成——它没有全局草稿
这是什么原理：模型的输出是一个 Token 一个 Token 往外吐的（你看到的「打字机效果」就是证据）。它写到某个词时，其实并不知道全文接下来要怎么收尾——本质上是不断地「预测下一个最合理的字块」。所以写长文章时后半段容易跑偏、结构松散：前面定好的框架，写到一半它自己淡忘了。
怎么做（提前给框架）：让 buddyme 写长内容时，先让它出大纲，你确认后，再让它「严格按这个大纲逐节展开，每节不超过 300 字」。这个动作等于把全局规划替它做好，局部生成时有章可循，跑偏率大幅下降。
原理五：温度与采样——同一个问题，答案为什么不一样
这是什么原理：模型每一步都会给所有候选字块打分，然后按概率「抽签」选出下一个。控制抽签方式的旋钮就是温度（Temperature）：温度低，永远选最高分的，输出稳定但呆板；温度高，低分选手也有机会上场，输出多样但更容易出错。温度超过 1.5，胡说八道的风险就很高了。要记住：温度只控制随机性，不控制聪明程度——觉得它变笨了，问题多半出在指令上，而不是温度上。
- 要代码、要提取数据、要格式严格的内容：低温（0-0.3），稳定第一。
- 要事实问答、数据分析：中低温（0.3-0.5），宁可保守。
- 要聊天、写文案：中温（0.5-0.7），自然又连贯。
- 要头脑风暴、起标题：中高温（0.8-1.0），发散一点没关系。
出错怎么办：三个常见「玄学问题」的标准答案
- 「它怎么把我上午说的忘了？」——上下文被截断了。开新窗口，先把背景用三句话重述一遍再继续。
- 「同样的问题，两次答案差很多？」——采样有随机性，正常现象。稳定需求用低温式指令；或者多生成几次挑最好的。
- 「它写得越来越好，但后半段完全跑题？」——逐字生成的天性。先定大纲再展开，或分段生成。
本节自检
- [ ] 知道 Token 是什么，贴长资料前会先想想值不值
- [ ] 习惯「一对话一任务」，长对话会主动让它总结
- [ ] 重要要求会在指令开头和结尾各出现一次
- [ ] 让它写长文前，会先要一份大纲
- [ ] 明白温度只管随机性，出质量问题先改指令
下一节我们把这些原理直接变成手艺：怎么写一条让 buddyme 一次听懂的指令。