学习笔记

工作流那篇的结尾留了一句话—— “再往后——当AI不只是按图纸施工，而是学会了自己画图纸，那就是智能体了。” 这篇，就讲这件事。 智能体：从按图施工到自己画图 工作流是把路线画好，AI照着跑。第一步查天气，第二步写建议，第三步存笔记。每一步都是人定的。AI不看路，只看图纸。 智能体把这个逻辑翻转了。 人只给终点——“帮我了解今天适不适合出门。“路怎么走，AI自己判断。 核心区别只有一个：谁来决定"下一步”。 工作流：人画路线，AI跑腿。 智能体：人定终点，AI自己找路。 智能体怎么运作的：一个四字循环 不需要代码。智能体的运行就是一个循环： 看 → 想 → 做 → 回头再看。 “帮我了解今天适不适合出门”—— 看：收到目标，检查当前状态 想：要出门，得知道天气。用户没说城市，默认成都吧。还需要空气质量吗？先查天气再说。 做：调用天气工具，查到"成都，晴，28°C” 回头再看：天气不错。还需要查别的吗？问一下用户要不要继续。目标基本完成。 每一步之后，智能体把新信息加进上下文，重新判断下一步。智能体每一步的"想"和"回头看"，都依赖上下文里积累了什么。上一步查到的天气、用户之前的偏好、还没完成的子目标——全靠上下文工程撑着。上下文工程是智能体的地基。 工作流 vs 智能体 工作流 智能体 路线 人提前画好的 AI自己规划 决定权 在每个节点人已经定了 AI每一步自己判断 可控性 高，每一步都知道会发生什么 中，可能跑偏 适合场景 流程固定、重复执行 目标明确但路径不确定 举例 每周自动整理AI新闻发邮件 “帮我研究一个选题，写篇文章” 工作流和智能体不是对立的。工作流是智能体的地基——不理解怎么串步骤，就没法理解智能体怎么自己规划步骤。上一篇说的"学工作流恰恰是为了驾驭智能体"，就是这个意思。 用扣子搭过 Bot？给它规则和工具，它自己判断怎么回答——这就是智能体。登录过 WorkBuddy，让它帮忙整理文档、填表格？也是一个智能体在电脑上干活。智能体不是未来概念。是已经在身边的东西。 驾驭工程：能动手，就得有缰绳 为什么对话AI不需要驾驭，智能体需要 跟AI聊天，聊崩了，重新发一条。 智能体不一样。它能读文件、写文件、删文件、发消息、操作软件。它能动手。 能动手，就有改错东西的风险。 这不是"智能体更聪明所以要管住"。是能力边界不同。对话AI的边界停在对话框里，无论如何伤不到桌面上的东西。智能体的手伸出来了——伸得越远，摔东西的概率越大。 自由越大，缰绳越要紧。 驾驭的三层机制 从松到紧，三层叠加： 第一层：规则约束。 在智能体开始干活前，先告诉它什么能做、什么不能做。“不要删除文件"“不确定的事先问"“回复用中文”。这些规则写在上下文的最前端——还记得上下文工程那篇的首因效应吗？放在最前面的东西，智能体最不容易忘。 但规则只是文字建议。智能体可以不遵守。越长的任务，上下文越被推远，规则越容易"沉底”。 第二层：审批关卡。 有些动作，智能体不能自己做——必须等人点头。删文件？弹确认框。发邮件？先预览。花超过1块钱？暂停等人审批。 这层不是依赖智能体听话，是依赖系统拦截。智能体不知道人在看着，它只是在等。 第三层：环境隔离。 最紧的一层。智能体跑在一个笼子里。能读的文件、能访问的网络、能用的工具——全部限定。即使智能体发了疯，破坏范围也是可控的。 三层叠起来：规则说方向，关卡管执行，环境兜底线。 Codex 的三个审批模式就是这三层的现实版——“从不审批"最松，“每一步都审批"最紧，“失败时审批"取中间。同一个智能体，同一个能力，不同的驾驭设置，就是不同的风险偏好。 ...

AI已经有工具了。能搜索、能读文件、能操作软件。 但每次完成一个任务，还是要手动喂好几轮。 想写一篇文章：先让AI查资料，查完了把结果复制下来；再开一轮对话，把资料喂进去让它列大纲；大纲出来了，复制；再开一轮，让它写初稿。三步——三场对话。人坐在中间，复制、粘贴、等待、再复制。 每一步AI都能做。只是不想当胶水。 不是AI做不到。是只给了它工具，没给它图纸。 工作流的三个关键词 工具调用，是给AI一把锤子。 工作流搭建，是给它一张图纸加整套工具，说"按这个顺序，从头做到尾"。 串联。 A步骤的输出，自动变成B步骤的输入。不用人在中间等着复制粘贴。 触发。 可以是手动——点一下"开始"。也可以是自动——每周日晚上九点，自己跑。 分支。 不是一条直线走到底。如果A结果是这样，走B；如果那样，走C。 人做什么？设计流程，判断结果。不再亲自执行每一步。 一个现实的例子：每周日晚九点，AI自动搜索本周AI新闻，整理成简报，存入笔记软件，发邮件到收件箱。五步，人只需要看最后那封邮件。 形成工作流的两股推力 工作流的出现，背后有两股推力。 第一股推力：单轮对话不够用。 真实任务从来不是一步。写文章、做调研、整理信息——每一步AI都能帮，但每一步都要人手动触发。人站在中间当胶水，这是最累也最没价值的环节。 第二股推力：全自动Agent太野。 2023年，AutoGPT横空出世。给一个目标，AI自己拆任务、自己执行。但很快问题暴露——让它调研AI行业动态，它可能先搜五十个网页，再看二十个视频，然后陷入无限循环反复改同一段文字。Token烧完了，产出约等于零。 很多时候不是不知道流程，是想让AI按既定的流程高效执行。不需要AI替人规划，需要AI替人跑。 工作流选了一条中间路线：人定流程，AI跑腿。 在可预测性和自动化之间，选择了可预测性优先。 工作流和Agent：谁说了算 讲到这里，一个疑问自然会冒出来：现在Agent这么火，工作流是不是过时了？ 用过扣子的人都有这种感受：界面让人感觉在搭一个"智能体"——给它工具、给它规则，它自己判断怎么干。但扣子同时也支持拖节点、连线、搭工作流。同一个界面里，两种模式共存。 这不是扣子的问题。这是工作流和Agent的底层关系：不是替代，是两层不同的逻辑。 核心区别只有一个：谁来决定"下一步做什么"。 工作流：人提前画好路线图。第一步查天气，第二步写建议，第三步存笔记。AI跑的时候不看路，只按图纸走。 Agent：人只给目标——“帮我了解今天适不适合出门”。AI自己判断：需要查天气吗？查几个城市？需要看空气质量吗？每做完一步，它自己决定下一步。 工作流 Agent 路线 人画好的 AI自己规划 可控性 高，每一步都知道会发生什么 低，可能跑偏 适合场景 流程固定、重复执行 目标明确但路径不确定 代表工具 n8n、Dify、Make 扣子智能体模式 一个Agent内部，本质上就是在实时生成工作流。它收到目标，自己画路线，自己执行，看结果，修正路线，继续。不理解工作流的逻辑——串联、分支、输入输出匹配——就没办法理解Agent在做什么，更谈不上调教它。 就像学车。手动挡让人理解离合、档位、转速的配合。自动挡把这些封装了。真出了状况，只会开自动挡的人不知道车在干嘛。 话说到这，一个更根本的问题该问了。 AI发展这么快。Agent越来越强。n8n这样的工具，还有必要学吗？ 有句话是这么说的：学的速度如果足够慢，那就不用学了——等学会的时候，它已经过时了。 这句话放在"学某个具体按钮在哪"上，是对的。放在"学工作流的思维"上，不对。 因为工作流不是一个工具，是一种组织任务的方式。串联、分支、触发、输入输出匹配——这些逻辑不会因为工具换代而失效。n8n可能会被取代，但"把复杂任务拆成可串联的步骤"这件事，永远不会过时。 更深一层：学工作流，恰恰是为了驾驭Agent。 Agent之所以跑偏，往往是因为目标给得太模糊、步骤太跳跃、中间缺少检查点。而工作流思维训练的，正是——把一个大目标拆成小步骤，在每个关键节点设置验证，确保上一步的输出能准确喂给下一步。这些能力，在放权给Agent的时候，反而更重要。 不是先学n8n再学Agent。是在学n8n的过程中，长出驾驭Agent的能力。 上手工作流的三个层次 从已经在做的事开始。 第一层：手动串联。 把一个复杂任务拆成几步，每一步写一条提示词，上一步的结果复制给下一步。虽然手动，但思维已经是工作流思维了。写公众号的过程——想选题、和AI对话走完思考、写初稿、改文字、排版、发布——本身就是一条流水线。只是现在每一步之间是人手动衔接的。 第二层：平台内置。 扣子的工作流模式——拖节点、连线、配参数，不写代码就能把AI调用、搜索、条件判断串起来。通义千问的百炼平台也内置了类似能力。不离开正在用的平台，就能体验"按流程跑"。 第三层：专用工作流工具。 n8n——开源、可自部署、四百多个节点，工作流领域最具代表性的工具。Dify——为AI原生设计，每个节点都围绕LLM。扣子——零门槛起步，已经在用了。Make——可视化最强，非AI场景也极强。 工具 定位 适合谁 n8n 通用工作流 + AI 愿意折腾、想要自主权 Dify AI原生应用平台 专注AI场景 扣子 AI Bot搭建 最快上手 Make 通用自动化 非AI场景也强 提示工程回答"怎么说"。 上下文工程回答"怎么管记忆"。 工具调用回答"怎么让AI动手"。 工作流搭建回答"怎么把事串起来"。 ...

“帮我查一下明天的天气。” 对着本地部署的AI对话框敲完这句话，看着回复，才发现它根本做不到。 不是不想做。是没有"查"这个能力。 AI能写诗、能翻译、能讨论哲学——为什么不能查个天气？为什么对话框里那个看似无所不能的东西，连这么简单的事都做不了？ 答案比想象中简单：它没有手。 AI 需要一双手 大语言模型的本质是一台预测引擎。输入一段文字，它预测下一段文字最可能是什么。它没有眼睛、连不上网、打不开文件。它的全部世界，就是塞进对话框的那段文字。 “查天气"这三个字对它来说，跟"写首诗"没有区别——都是在预测下一个token。但它预测出来的天气，可能是去年的，可能是编的。 所以问题变成了：怎么给这台预测引擎装上一双能伸出去的手？ 这就是工具调用。 工具调用就三个动作 不需要理解代码。就三个动作在循环： 动作一：告诉AI有哪些工具可用。 提前写好一份清单，列出AI能调用的资源——比如"网页搜索"“读文件"“发邮件”。每个工具附带一份说明书，写清楚叫什么、能干嘛、需要什么参数。 动作二：AI判断该调哪个、怎么调。 AI收到消息后，扫一眼清单。如果发现聊天解决不了，而清单上有工具能解决——就决定调动那个工具，并填好参数。 动作三：系统执行，把结果喂回来。 AI只负责"说要用哪个工具”，真正去搜索、读文件、跑命令的，是电脑或服务器。执行完把结果塞回对话，AI基于结果继续回答。 工具调用的三种场景 工具调用不是一个"功能开关”，取决于AI"站在哪里"。 网页端。 最常见的形态。ChatGPT网页版能搜索、能画图、能跑代码——这些就是被预设好的工具。但能看到哪些、能调哪些，是平台定好的，没法自己加。 API调用。 开发者通过API接入。工具完全自己定义——想给AI什么能力，就写什么工具。最灵活，但需要写代码。 AI Agent。 跑在本地或服务器上的AI客户端。能调用shell命令、读写文件、操作软件。装什么工具就能调什么，权限边界自己控制。 三种场景一层比一层自由。要彻底搞懂工具调用，本地Agent是最短路径——每一步都看得见。 一个真实的例子。复盘上周微信公众号时，我让AI帮我看一眼我已经记录在本地笔记中的数据，： “查看《上下文工程》的阅读量” AI没有直接回答。它在后台调用了shell命令，在我电脑上执行了文件搜索。拿到搜索结果，再告诉我"23"。看起来是一问一答，背后是一次完整的工具调用循环。 工具调用的四个组件 组件 做什么 谁负责 工具定义 描述工具叫啥、能干嘛、要什么参数 人提前写好 工具选择 AI判断该用哪个工具 AI自己判断 工具执行 真正去搜索、读文件、跑命令 系统执行 结果整合 AI把返回结果消化，继续对话 AI自己 四个组件里，最核心也最容易困惑的是第一个——工具定义。 一个工具，就两部分： ① JSON说明书——给AI看的菜单。告诉AI：我叫什么、我能干什么、我需要什么参数。 主流格式就两种，本质一模一样： OpenAI风格—— { "name": "get_weather", "description": "查询指定城市的当前天气", "parameters": { "city": { "type": "string", "description": "城市名称，例如北京、上海" } } } MCP风格——换个字段名，结构不变： { "name": "get_weather", "description": "查询指定城市的当前天气", "input_schema": { "properties": { "city": { "type": "string", "description": "城市名称" } } } } ② 执行代码——真正干活的。AI不看它，也不执行它： ...

跟AI聊得好好的。第一轮交代了背景、要求、格式，AI按这些规矩生成了好几轮。聊到第十轮，它忽然忘了最开始说过什么——语气变了，方向偏了，连那个费了半天劲才调好的格式也丢了。 不是AI变笨了。 是它的记忆空间被填满了。 提示词写得好不好，决定第一轮。上下文管得好不好，决定第十轮还能不能稳住。这是从"会说"到"会管"的跨越。 两个刚性限制 理解上下文工程，先从理解约束开始。 第一，LLM没有真正的长期记忆。 模型每一轮推理，能"看到"的东西只有当前上下文窗口里的内容——系统提示、对话历史、刚发来的消息。窗口之外的一切，对模型来说等于不存在。说"之前说过"，它只能在对话历史里恰好还没被挤出窗口的那部分里找——一旦超出窗口，这段记忆就彻底丢失了。不是它不想记住，是它没有一个"存档"的地方。 第二，上下文窗口不是无限免费的。 128K、200K、1M token——窗口越来越大，但每塞进去一个token都有代价。计算代价：推理变慢变贵。注意力代价：信息越多，模型对每条信息的关注越稀疏，关键指令可能被淹没在大量无关内容里。机会代价：劣质信息占住位置，好信息就塞不进去了。 两个约束叠加在一起，产生了一个核心问题：怎么让有限的空间装进最有价值的信息，并且排列成让模型最容易理解和使用的结构。 这就是上下文工程。 什么是上下文工程 三层定义，从直觉到精确。 直觉层：管理跟AI之间的记忆空间——决定让它记住什么、忘记什么、先看什么、后看什么。 操作层：在有限token窗口内，通过设计输入的结构、顺序和取舍，最大化输出质量的方法。 工程层：一套系统性的方法论，涵盖容量管理、信息密度、位置效应、上下文污染、信息的生命周期管理和跨会话的上下文复用。 核心的意象是这样——把AI想象成一个人，坐在一张固定大小的书桌前。桌面的面积是有限的，摆满了，再放新的就得把旧的撤下去。上下文工程不是教它怎么干活，而是设计这张桌子上的布局：什么放在手边最顺手的位置，什么叠在旁边备用，什么已经没用了、该直接丢进垃圾桶。 和提示工程的边界 写这个系列以来，一个反复思考的问题是：上下文工程和提示工程，到底是什么关系？ 不是包含，是交汇。 提示工程打磨的是一条消息的质量——措辞、示例、格式、角色设定。上下文工程设计的是整场对话的信息环境。 它们交汇的地方在这里：提示词本身占用token，是上下文的一部分；上下文的结构反过来影响每条提示词的效果。一个写好提示词但管不好上下文的人，聊着聊着AI就忘了；一个精于上下文布局但写不好单条提示的人，每句话都问不到点子上。 一句话区分：提示工程回答"怎么说"，上下文工程回答"给AI看什么、按什么顺序看"。 管理什么：七种对象 进入上下文窗口的全部信息，都是上下文工程要管的东西。 系统提示（System Prompt）。 上下文里最持久的部分，定义角色、行为边界、输出格式。它是上下文工程的地基——写什么、写多长、怎么组织，直接影响整个会话的质量上限。 用户输入（User Message）。 单条提示词是提示工程的产物。上下文工程不重写它，但判断它放在什么位置、密度是否合适、和前面信息有没有冲突。 对话历史（Conversation History）。 体积最大、增长最快的部分。聊得越久，越早的内容越被挤出。关键问题是：什么东西保留，什么东西可以——甚至应该——被主动遗忘。 外部检索结果（Retrieved Context）。 搜索结果和文档片段注入上下文的位置、数量和格式，决定了模型能不能有效利用。塞太多，淹没核心指令；塞太少，信息不足。 工具调用输出（Tool Output）。 Agent调用工具返回的结果会被追加进上下文。如果工具返回了5000行日志全部塞进去，核心任务就被稀释了。需要截断、摘要、结构化，或者判断根本不值得放进去。 少样本示例（Few-Shot Examples）。 提示工程里最有效也最吃token的东西。三四个精心挑选的示例，可能比几十个平庸的示例效果好得多。选几个、选哪些、放在什么位置——这是提示工程和上下文工程的交汇带。 结构化信息（Structured Context）。 项目规则、记忆文件、风格手册——预先写好、长期复用的上下文材料。怎么组织、什么时候更新、在什么时机加载。Skill本质上就是这种思想的产物。 六个核心问题 这才是上下文工程真正的"硬核"部分。 容量管理 上下文窗口的token上限是硬天花板。系统提示占多少？对话历史留多少？工具返回预留多少？ 每个部分不是越大越好。系统提示写得像长篇小说，等于侵占模型"看"真正任务的空间。几百行规则塞进去，模型对每条规则的注意力都被稀释了。容量管理的第一课：不是能塞多少塞多少，而是只塞必要的。 信息密度 同样的1000个token，可以是一段散乱的对话记录，也可以是一组结构化的要点。 上下文工程追求高密度——让每token承载的信息量最大化。格式化的标签、分层结构、紧凑的要点，不是写给人类看的排版，是控制单位token的信息产出比。把信息组织好再塞进去，比随手丢进去再期望AI自己理清楚，要可靠得多。 位置效应 模型对上下文不同位置的关注度不一样。 开头的指令最容易"记住"——首因效应。结尾的内容对当前输出影响最大——近因效应。中间的部分则容易被忽略，这就是"迷失在中间"现象。 上下文工程利用这个规律：核心约束放开头，最新状态放结尾，参考信息放中间但要加结构锚点——小标题、编号、标签——把模型的注意力拉回来。 上下文污染 一条错误、矛盾或过时的信息一旦进入窗口，会持续影响后续所有输出。 更隐蔽的是自我污染：模型自己生成的不准确内容被注入后续上下文，形成错误循环——AI说错了一句话，这句话被当成事实写进下一轮的上下文，然后AI基于这个错误继续推理。很多时候，不是信息不够，是信息不对。 上下文工程的一个重要动作，就是识别和阻断这种污染——在错误信息进入窗口之前拦下来，或者在发现之后主动清除。 记忆的粒度与生命周期 不是所有信息都应该在上下文里活一样久。 有些信息全程保持——任务目标、核心约束、输出格式。有些只在一轮有效——一次搜索的结果、一个临时变量的值。有些需要"降级存储"——把五轮详细对话压缩成三行摘要，保留关键结构但不占用多少空间。 上下文工程要设计这种分层机制：热记忆持续在线，温记忆被压缩存档，冷记忆直接丢弃。 上下文复用 一个精心搭建的上下文环境——系统提示+规则文件+参考文档——能不能被复用？ ...

“知道想要什么，并且能描述出来。” 这是写《AI时代最重要的四个能力》时，给第一个能力起的名字：懂诉求。 描述出来——到底怎么描述？ 这件事有个名字，叫提示工程。不神秘。不需要会写代码。就是把心里模糊的想法，翻译成AI能懂的句子。反复翻译，反复调，直到AI给的东西对得上心里那个模糊的形状。 基础认知 编写提示不需要数据科学或机器学习背景——人人都可以做到。但写好提示并不简单，它涉及模型选择、训练数据、配置参数、措辞、语气、结构和上下文等多个变量，需要持续学习和实践。 LLM的本质 LLM 的本质是预测引擎。它接收一段连续文本作为输入，基于训练数据预测下一个最可能的 token，然后将预测结果追加到文本末尾，如此循环往复，逐步生成完整输出。 提示工程的定义 提示工程是设计高质量提示以引导 LLM 生成准确输出的过程。它适用于文本摘要、信息提取、问答、分类、翻译、代码生成等多种任务，需要针对具体模型优化提示并调整各项输出配置。 迭代过程 提示工程是一个迭代过程。模型选择、配置参数、措辞等多个变量都会影响效果，一次写出完美提示几乎不可能，需要反复尝试和调整才能获得满意的结果。 输出配置 输出长度（Token Limit） 输出长度控制模型生成的最大 token 数量。减少该值不会让输出更简洁，只是到上限即停止预测。短输出需求仍需在提示中明确要求简洁。 采样控制 Temperature（随机性） Temperature 控制模型输出的随机程度。低值（接近 0）输出更确定、保守；高值（接近 1）输出更有创造性、多样。数学或事实类任务建议设为 0。 Top-K（词频筛选） Top-K 限定模型仅从概率最高的 K 个 token 中选取下一个词。K 值越小，可选范围越窄，输出越保守和确定；K 值越大，候选池越宽，输出越多样和不可预测。 Top-P（累积概率筛选） Top-P 限定模型仅从累计概率达到 P 的最小 token 集合中采样，候选数量随概率分布动态调整。设 Top-P 为 0 则退化为仅选最可能 token（Temperature 和 Top-K 失效）；设为 1 则不排除任何 token。 综合应用 通用起点：temperature=0.2，top-P=0.95，top-K=30（连贯、有适度创造性）。 需要创造性：temperature=0.9，top-P=0.99，top-K=40。 需要确定性：temperature=0.1，top-P=0.9，top-K=20。 唯一正确答案：temperature=0。 需注意：自由度过高会降低生成文本的相关性，设置不当还可能引发"重复循环错误"（模型陷入重复输出相同词语或句子的循环）。 基础提示 提示的基本结构 一个设计良好的提示通常由以下要素构成，写作时可将其作为自查清单： 任务指令：明确告诉模型要完成什么任务（分析、总结、分类、生成等） 上下文：提供任务所需的背景信息和约束条件 示例：通过少样本示例帮助模型理解期望的输出模式 输出格式：指定输出的结构（纯文本、列表、JSON、Markdown 表格等） 角色与语气：定义模型以什么身份、什么风格输出 并非每个提示都需要所有要素——简单任务可能只需一句指令，复杂任务则需要充分填充。关键在于根据任务复杂度有意识地组合这些要素。 ...