AI工作台搭建指南：Skill组合与工作流编排实战

1. 从单点工具到组合拳：为什么你需要一个AI工作台

很多人用AI的方式还停留在“打开一个对话框，问一个问题，复制答案，关掉”的阶段。这种用法不是不行，但效率天花板极低。你每次都在重新交代背景、重新设定角色、重新调整输出格式，大量时间浪费在重复的“热身”动作上。而真正把AI用出生产力的人，早就不这么干了。

他们做的事情，用一句话概括就是：把多个Skill组合起来，搭一个属于自己的AI工作台。

所谓Skill，你可以把它理解成一个“技能包”或者“能力插件”。一个Skill负责一件事——比如专门做会议纪要整理、专门做代码审查、专门做竞品分析、专门做周报生成。单独一个Skill已经能解决一个具体问题，但真正的威力在于把它们串起来、叠起来、编排起来，形成一个自动化的工作流。这就是“AI工作台”的核心思路。

这篇文章适合谁看？三类人：第一类是对AI工具有基本使用经验，但还没形成系统工作流的职场人；第二类是正在探索Agent开发、想理解Skill编排逻辑的技术爱好者；第三类是已经在用各种AI平台，但觉得每次都要手动切换、重复输入、效率上不去的重度用户。不管你是哪一类，接下来的内容都会给你一套可以直接抄作业的方案。

我自己的AI工作台从最初的两三个Skill，到现在稳定运行十几个Skill的编排链路，中间踩了不少坑，也总结出了一些只有实际用过才知道的门道。下面我把整套思路和实操细节拆开讲。

2. 核心思路拆解：Skill组合的底层逻辑

2.1 单个Skill的局限性在哪里

先说说为什么单个Skill不够用。假设你有一个“写周报”的Skill，它的提示词写得很好，能根据你提供的工作内容生成结构清晰的周报。但实际使用中你会发现几个问题：

第一，输入不规范。你每次给它的原始信息格式都不一样，有时候是零散的几句话，有时候是一堆会议记录，有时候是任务清单。Skill本身如果没有预处理能力，输出质量就会波动。

第二，上下游断裂。周报写完之后，你可能还需要把它转成邮件格式发给领导，或者提取关键数据填入项目管理系统。这些动作如果每次都手动做，Skill的价值就被稀释了。

第三，缺乏上下文积累。一个好的周报应该能体现你本周和上周工作的连续性，但单次调用的Skill没有记忆，每次都是从零开始。

这三个问题的本质是：单个Skill只能完成一个原子操作，而真实工作流是多步骤、有依赖、需要上下文传递的。所以我们需要组合。

2.2 组合的基本模式：串行、并行与条件分支

Skill组合不是简单地把几个Skill排在一起就完事了。根据我实际搭建的经验，常见的组合模式有三种：

串行模式是最基础的。Skill A的输出作为Skill B的输入，B的输出再给C。比如：原始语音转文字 → 文字整理成结构化笔记 → 笔记提炼成行动项 → 行动项分配责任人并生成通知。这条链路上每一步都依赖上一步的结果，顺序不能乱。

并行模式适合处理独立子任务。比如你拿到一份长文档，同时需要“提取关键数据”“生成摘要”“检查合规风险”三个结果。这三个任务互不依赖，可以并行调用三个Skill，最后汇总。并行模式的关键是汇总环节的设计——你得有一个“合并Skill”来整合多路输出，否则结果就是散的。

条件分支模式是进阶玩法。根据上一步的输出内容，决定下一步走哪条路。比如一个“客户反馈处理”工作流：如果反馈是投诉类，走“投诉处理Skill”；如果是咨询类，走“知识库检索Skill”；如果是建议类，走“产品需求整理Skill”。这种模式需要你在编排层写清楚判断条件。

我自己的工作台里，三种模式都有用到。最常用的是串行加并行的混合结构——先串行做预处理和清洗，然后并行跑几个分析Skill，最后串行做汇总和格式化。

2.3 为什么强调“属于自己的”工作台

市面上有很多现成的AI工作流平台，为什么还要自己搭？核心原因是：通用方案解决通用问题，但你的工作流是独特的。

你的行业术语、你的输出格式偏好、你的审批流程、你常用的数据源——这些东西没有哪个平台能完全适配。自己搭工作台的过程，本质上是在把你的隐性知识显性化、把你的工作习惯结构化。一旦搭好，它就是一个完全贴合你个人工作方式的效率引擎。

而且，自己搭的工作台是可迭代的。你今天发现某个环节输出不好，改一下那个Skill的提示词就行；明天有了新的需求，加一个Skill进去就行。这种灵活性是现成平台给不了的。

3. 搭建前的准备工作：别急着写提示词

3.1 梳理你的高频工作流

很多人一上来就开始写Skill的提示词，这是典型的本末倒置。正确的第一步是：拿出纸笔，列出你每周重复三次以上的工作流程。

注意关键词是“重复三次以上”。偶尔做一次的事情不值得做成Skill，因为投入产出比不划算。只有高频、重复、有固定模式的工作，才值得自动化。

我当初梳理的时候列了二十多条，然后按频率和复杂度筛了一遍，最后留下八条核心工作流。这八条覆盖了我日常80%的重复性工作。你可以用下面这个表格来梳理：

这张表的关键作用是帮你分清优先级。先做那些频率高、步骤多、耗时长的，效果立竿见影。

3.2 确定你的技术底座

“技术底座”这个词听起来很唬人，其实就是在问：你打算在哪里跑这些Skill？

目前主流的选择有几类。一类是直接用大模型平台的对话界面，通过系统提示词来定义Skill，手动串联。这种方式门槛最低，但自动化程度也最低，适合刚起步的阶段。另一类是用支持工作流编排的平台，可以可视化地拖拽节点、连接Skill、设置条件分支。这种方式适合有一定技术基础、想要更高自动化程度的用户。还有一类是自己写脚本调用API，把Skill编排逻辑写在代码里。这种方式最灵活，但需要编程能力。

我的建议是：从第一类开始，逐步过渡到第二类，有需要再上第三类。不要一上来就追求全自动，先把单个Skill打磨好，再考虑编排。

3.3 建立你的提示词素材库

在正式搭建之前，还有一个准备工作非常重要：建一个提示词素材库。

什么意思？就是把你平时用得好的一些提示词片段、输出格式模板、角色设定语句，统一存到一个地方。比如：

• 你常用的角色设定：“你是一位有十年经验的财务分析师，擅长用通俗语言解释复杂财务概念”
• 你偏好的输出格式：“用Markdown表格输出，列名为：项目、现状、风险、建议”
• 你常用的约束条件：“不要使用专业术语，如果必须使用请用括号解释”

这些东西在你写每个Skill的时候都会反复用到。提前整理好，写Skill的时候直接拼装，效率会高很多。我自己的素材库分了四个文件夹：角色设定、输出模板、约束条件、示例样本。每次写新Skill，从这四个文件夹里各取所需，十分钟就能拼出一个可用的初版。

4. 核心Skill的设计与实现细节

4.1 输入预处理Skill：把脏活累活干掉

在任何工作流里，输入预处理都是最不起眼但最重要的环节。原始输入往往是脏的——格式混乱、信息冗余、关键信息埋在废话里。如果预处理没做好，后面的Skill再强也是垃圾进垃圾出。

我设计的输入预处理Skill主要做三件事：

第一，格式归一化。不管你丢进来的是语音转文字、手打笔记、还是复制的聊天记录，统一转成结构化的Markdown格式。这一步的关键是定义好“结构化”的标准。我的标准是：标题、时间、参与人、正文、待办事项，五个字段。所有输入都往这五个字段里塞。

第二，信息去噪。去掉语气词、重复内容、无关寒暄。这一步看起来简单，但提示词要写得很细。比如我会明确告诉模型：“删除所有‘嗯’‘啊’‘那个’‘就是说’等语气词；删除与工作内容无关的闲聊；如果同一信息出现多次，只保留最完整的一次表述。”

第三，关键信息提取。从去噪后的内容里，提取出人名、时间节点、数字、决策结论这四类关键信息，单独列出来。这一步的目的是为后续Skill提供“索引”。

这个Skill的提示词我改了十几版才稳定下来。最大的坑是：不要试图让一个Skill同时做归一化和提取。我一开始图省事，把两个任务写在一个提示词里，结果模型经常顾此失彼。后来拆成两个独立的Skill，串行执行，稳定性大幅提升。

4.2 核心处理Skill：每个只做一件事

核心处理Skill是整个工作台的主体。设计原则只有一条：一个Skill只做一件事，做到极致。

我见过很多人写Skill，恨不得一个提示词解决所有问题。结果就是每个环节都做得马马虎虎。正确的做法是拆——把一个大任务拆成若干个原子任务，每个原子任务对应一个Skill。

举个例子，“竞品分析”这个大任务，我拆成了四个Skill：

• 信息采集Skill：从指定来源抓取竞品动态，输出原始信息列表
• 分类归档Skill：把原始信息按“产品更新”“市场动作”“人事变动”“融资情况”分类
• 影响分析Skill：针对每条信息，分析对我方产品的潜在影响
• 报告生成Skill：把分析结果整合成结构化报告

每个Skill的提示词都很短，但很精准。比如分类归档Skill的提示词核心就一句话：“将以下信息按产品更新、市场动作、人事变动、融资情况四类归档，每类下按时间倒序排列，如果某条信息同时属于多个类别，只归入最相关的一类。”

这种“短提示词+单一职责”的设计，好处是调试极其方便。哪个环节出问题，直接改那个Skill就行，不会牵一发而动全身。

4.3 输出格式化Skill：让结果直接可用

很多人忽略了输出格式化的重要性。辛辛苦苦跑出来的结果，格式乱七八糟，还得手动整理一遍，自动化就失去了意义。

输出格式化Skill的核心任务是：把上游Skill的输出，转成你最终需要的格式。这个格式可能是邮件正文、可能是PPT大纲、可能是Excel表格的CSV格式、可能是即时通讯工具的消息格式。

我常用的输出格式化Skill有三个：

• 邮件格式化：把内容转成正式邮件格式，包含称呼、正文、落款、附件说明
• 表格格式化：把内容转成Markdown表格或CSV，方便直接粘贴到表格软件
• 消息格式化：把内容转成适合在即时通讯工具里发送的短段落格式，每段不超过三行

这三个Skill的提示词里，我都会加上具体的格式示例。比如邮件格式化Skill里，我会贴一个完整的邮件模板作为参考。模型看到示例，输出格式的准确率会高很多。

4.4 质量检查Skill：最后一道防线

质量检查Skill是我踩了很多坑之后才加上的。它的作用是：在输出最终结果之前，自动检查一遍常见问题。

检查项包括：是否有事实性错误（比如把A的数据安到B头上）、是否有格式错误（比如表格列数不对）、是否有遗漏（比如要求输出五个点只输出了三个）、是否有敏感信息（比如不小心把内部数据带出来了）。

这个Skill的提示词设计有个技巧：不要让它“检查并修改”，而是让它“检查并报告”。因为让模型同时做检查和修改，它往往会为了修改而修改，把原本正确的内容改错。正确的做法是让它输出一份检查报告，列出发现的问题，然后由你决定是否修改，或者再跑一个专门的修改Skill。

5. 实操：从零搭建一个会议纪要工作台

5.1 场景定义与流程设计

光讲理论没意思，我拿一个最常用的场景——会议纪要整理——来完整走一遍搭建过程。

先定义场景：你每天要参加多个会议，会议有录音转文字的记录，你需要把记录整理成结构化的会议纪要，提取行动项，分配给责任人，并生成一封通知邮件。

整个流程拆成五步：

1. 输入预处理：把原始录音转文字整理成结构化文本
2. 信息提取：提取会议主题、参与人、讨论要点、决策结论、行动项
3. 行动项分配：给每个行动项指定责任人和截止时间
4. 纪要生成：整合成标准格式的会议纪要
5. 邮件生成：把纪要转成通知邮件

对应五个Skill，串行执行。

5.2 每个Skill的提示词设计与参数说明

Skill 1：输入预处理

提示词核心逻辑：

你是一个文本预处理助手。输入是一段会议录音转文字的内容。 请完成以下操作： 1. 删除所有语气词（嗯、啊、那个、就是说、然后呢等） 2. 删除重复表述，同一信息只保留最完整的一次 3. 按发言顺序整理，每段发言标注发言人（如果能识别） 4. 输出格式：纯文本，每段发言之间空一行

这个Skill不需要输出结构化数据，只需要把文本洗干净。参数上，我设置了“温度”为0.3，因为预处理不需要创造性，越稳定越好。

Skill 2：信息提取

提示词核心逻辑：

你是一个会议信息提取助手。输入是一段清洗后的会议记录。 请提取以下信息并以JSON格式输出： - 会议主题（一句话概括） - 参与人列表 - 讨论要点（列表，每条不超过50字） - 决策结论（列表） - 行动项（列表，每条包含：事项描述、建议责任人、建议截止时间） 如果某项信息在原文中没有明确提及，对应字段填“未提及”。

这个Skill的输出是结构化的JSON，方便后续Skill解析。温度设为0.2，因为提取任务需要高准确性。

Skill 3：行动项分配

提示词核心逻辑：

你是一个任务分配助手。输入是行动项列表和参与人列表。 请为每个行动项指定责任人，规则如下： 1. 如果原文中已明确责任人，保持不变 2. 如果未明确，根据行动项内容与参与人职责的匹配度推荐 3. 如果无法判断，标记为“待确认” 同时，根据行动项的紧急程度建议截止时间： - 紧急：24小时内 - 重要：3个工作日内 - 常规：本周内 输出格式：Markdown表格，列名为：行动项、责任人、截止时间、优先级

这个Skill需要一点判断力，温度设为0.5，给它一定的灵活空间。

Skill 4：纪要生成

提示词核心逻辑：

你是一个会议纪要撰写助手。输入是会议主题、参与人、讨论要点、决策结论、行动项表格。 请生成一份标准格式的会议纪要，格式如下： # 会议纪要 ## 基本信息 - 主题： - 时间： - 参与人： ## 讨论要点 （分点列出） ## 决策结论 （分点列出） ## 行动项 （表格形式） 要求：语言简洁正式，不添加原文没有的信息。

温度设为0.3，保持稳定输出。

Skill 5：邮件生成

提示词核心逻辑：

你是一个邮件撰写助手。输入是一份会议纪要。 请生成一封通知邮件，格式如下： 主题：【会议纪要】+ 会议主题 正文： 各位好， 以下是本次会议的纪要，请查阅。 （粘贴会议纪要正文） 如有疑问请随时沟通。 此致 敬礼 要求：邮件正文中不要重复“会议纪要”标题，直接放内容。

温度设为0.4。

5.3 串联与调试：第一次跑通全流程

五个Skill写完之后，先别急着串联。逐个单独测试，确保每个Skill在典型输入下都能稳定输出。

我的测试方法是：准备三组测试数据——一组标准输入（格式规范、信息完整）、一组边界输入（信息缺失、格式混乱）、一组极端输入（超长文本、多语言混杂）。每个Skill都要在这三组数据上跑通。

单独测试通过后，开始串联。串联的时候最容易出的问题是格式不兼容——Skill A输出的JSON，Skill B解析不了；Skill C输出的表格，Skill D当成纯文本处理了。

解决方法是：在每两个Skill之间加一个“格式转换”说明。比如在Skill 2和Skill 3之间，我会明确告诉Skill 3：“输入是JSON格式，包含以下字段：...”。这样模型就知道该怎么解析上游的输出。

第一次跑通全流程大概花了两个小时，中间调试了七八次。主要卡在行动项分配的准确性上——模型有时候会把行动项分配给不相关的人。后来我在提示词里加了一条：“如果行动项涉及多个参与人，选择职责最相关的一人作为主责任人，其他人列为协作人。”这个问题就基本解决了。

5.4 效果验证与迭代优化

跑通之后，我用了两周时间来验证和迭代。每天的实际会议记录都跑一遍，记录哪些环节输出好、哪些环节需要手动修改。

两周下来，发现三个高频问题：

第一，行动项提取有遗漏。有些行动项藏在讨论过程中，没有用“行动项”这个词明确标出。解决方案是在Skill 2的提示词里加一条：“注意识别隐含的行动项，比如‘这个事谁来跟进一下’‘下周之前需要搞定’等表述。”

第二，责任人分配有时不合理。模型倾向于把任务分配给发言最多的人，而不是最相关的人。解决方案是在Skill 3的提示词里加入参与人的职责描述作为参考。

第三，邮件格式偶尔跑偏。有时候会加上一些不必要的客套话。解决方案是在Skill 5的提示词里加一条：“不要添加原文没有的客套话，保持简洁。”

迭代三次之后，整个工作流的准确率从最初的70%左右提升到了90%以上。剩下的10%主要是极端情况，手动改一下就行。

6. 常见问题与排查技巧实录

6.1 Skill之间“打架”怎么办

这是组合使用中最常见的问题。表现是：Skill A的输出被Skill B误解，或者Skill B的输出风格被Skill C带偏。

根本原因是Skill之间的边界不清晰。每个Skill都应该有明确的“输入契约”和“输出契约”——我接受什么格式的输入，我保证输出什么格式的结果。

排查方法：把每个Skill的输入输出单独打印出来，逐个检查。如果发现某个Skill的输出格式不稳定，就在它的提示词里加格式约束，并且给出明确的示例。

我自己的经验是：在提示词里加一句“无论输入如何，你的输出必须严格遵循以下格式”，然后附上格式模板。这句话能解决80%的格式漂移问题。

6.2 输出质量不稳定的排查思路

同样的输入，有时候输出很好，有时候输出很差。这种波动性在组合工作流里会被放大——上游一个小波动，下游可能变成大偏差。

排查步骤：

1. 先定位是哪个Skill的输出不稳定。逐个Skill单独跑，看哪个环节的波动最大。
2. 检查那个Skill的提示词是否有歧义。常见的歧义来源包括：任务描述不够具体、格式要求不够明确、缺少示例。
3. 调整温度参数。需要稳定输出的Skill，温度调到0.2-0.3；需要一定灵活性的，0.4-0.6；需要创造性的，0.7以上。
4. 如果还不行，考虑把那个Skill拆成两个更细的Skill。

我遇到过一个典型案例：一个“摘要生成”Skill，有时候输出三句话，有时候输出三段话。后来发现是提示词里写了“简洁摘要”，但没定义“简洁”的标准。改成“输出不超过100字，分2-3句话”之后，就稳定了。

6.3 性能瓶颈与优化方向

当Skill数量多起来之后，整个工作流的执行时间会变长。如果每个Skill平均需要10秒，十个Skill串行就是100秒，体验就很差了。

优化方向有几个：

并行化：把互不依赖的Skill改成并行执行。比如“信息提取”和“情感分析”可以同时跑，不用一前一后。

缓存：对于重复的输入，缓存上一次的输出结果。比如同一份会议记录如果跑了两次，第二次直接返回缓存结果。

精简Skill：定期审查每个Skill，看是否有可以合并的。有些Skill拆得太细，反而增加了编排开销。

异步执行：对于耗时长的Skill，改成异步调用，不阻塞主流程。等结果出来再通知。

我自己的优化经验是：先把串行链路跑通，再考虑并行化。不要一上来就追求极致性能，那样会陷入过度设计的陷阱。

6.4 常见问题速查表

7. 进阶玩法：让工作台自己“长”出新能力

7.1 Skill的版本管理与回滚

当你有了十几个Skill之后，管理就成了问题。改了一个Skill，可能影响下游三个Skill。没有版本管理，出了问题都不知道回滚到哪个版本。

我的做法是：每个Skill的提示词都存成独立文件，用日期+版本号命名。比如meeting-preprocess-v3-20250115.md。每次修改都新建一个版本，不覆盖旧版本。同时在文件头部记录修改原因和影响范围。

这样做的成本很低，但收益很大。有一次我改了一个提取Skill的规则，导致下游三个Skill的输出全部异常。因为保留了旧版本，五分钟就回滚了。

7.2 用“元Skill”自动生成新Skill

这是一个比较进阶的玩法：写一个“Skill生成器”Skill，它的输入是你对某个新任务的自然语言描述，输出是一个完整的Skill提示词。

比如你输入：“我需要一个Skill，能把英文技术文档翻译成中文，并且保留专业术语的英文原文。”这个元Skill就会输出一个包含角色设定、任务描述、格式要求、示例的完整提示词。

这个玩法的好处是：降低新Skill的创建门槛。你不需要每次都从零开始写提示词，只需要描述需求就行。当然，生成的提示词还需要你手动微调，但至少有了一个不错的起点。

我自己的元Skill提示词核心逻辑是：

你是一个Skill设计专家。用户会描述一个任务需求。 请生成一个完整的Skill提示词，包含以下部分： 1. 角色设定（一句话） 2. 任务描述（分步骤） 3. 输入格式说明 4. 输出格式说明（附示例） 5. 约束条件（至少三条） 6. 异常处理（至少两条） 输出格式：Markdown，可直接复制使用。

7.3 工作流的监控与日志

当工作流跑在后台自动执行时，你需要知道它有没有出问题。我的做法是：每个Skill执行后都写一条日志，记录执行时间、输入摘要、输出摘要、是否成功。

日志不需要很复杂，一个简单的文本文件就行。关键是格式要统一，方便后续检索。我的日志格式是：

[时间戳] [Skill名称] [状态] [输入摘要] [输出摘要] [耗时]

有了日志之后，排查问题就快多了。哪个Skill经常失败、哪个Skill耗时最长、哪个Skill的输出经常被下游拒绝，一目了然。

7.4 从个人工作台到团队协作

当你自己的AI工作台跑顺了之后，很自然会想到：能不能让团队也用起来？

我的经验是：先个人跑通，再团队推广。个人跑通的标准是：连续两周，每天使用，准确率稳定在90%以上。达到这个标准之后，再把Skill分享给团队。

团队协作的关键是统一输入输出标准。每个人的使用习惯不同，如果输入格式五花八门，Skill的稳定性就会下降。所以推广之前，先制定一个简单的使用规范——比如“所有会议记录统一用XX格式提交”“所有输出统一用XX模板”。

另外，团队使用时要特别注意权限管理。有些Skill可能涉及敏感数据，不是所有人都能用。我的做法是给Skill打标签，分为“公开”“团队”“个人”三级，不同级别对应不同的使用权限。

8. 我踩过的坑与实战心得

8.1 不要追求“大而全”的工作台

我一开始的野心很大，想搭一个覆盖所有工作场景的超级工作台。结果花了大量时间在编排上，每个Skill都做得不精。后来砍掉了三分之二的Skill，只保留最高频的八个，反而效果好得多。

少即是多。一个精炼的、每天都能用上的工作台，比一个庞大但很少跑通的工作台有价值得多。

8.2 提示词不是越长越好

新手容易犯的错误是：把提示词写得非常长，恨不得把所有可能的情况都写进去。结果模型被过多的约束搞晕了，输出反而更差。

我的经验是：提示词的长度和任务的复杂度成正比，但有一个上限。单个Skill的提示词，控制在300-500字比较合适。超过这个长度，就要考虑拆分成多个Skill。

8.3 定期“体检”你的工作台

工作台搭好之后不是一劳永逸的。你的工作内容会变，AI模型会更新，原来的Skill可能慢慢就不适用了。

我每个月会做一次“体检”：把每个Skill单独跑一遍，看输出是否还符合预期。如果某个Skill连续三次输出不理想，就标记为“待优化”，安排时间修改。

这个习惯帮我避免了很多“温水煮青蛙”式的问题——Skill慢慢变差，但你一直没发现，直到某天出了大问题才意识到。

8.4 保持手动兜底的能力

不管工作台多智能，永远要保留手动处理的能力。我见过有人完全依赖自动化工作流，结果某天模型服务出问题，整个工作就瘫痪了。

我的做法是：关键环节保留手动入口。比如会议纪要工作流，如果自动生成的结果不理想，我可以手动修改任何一个环节的输出，然后继续往下跑。这种“半自动”的模式，比“全自动但不可控”要实用得多。

8.5 记录每一次“意外的好结果”

有时候模型会输出一些超出预期的好结果——比如一个特别精准的总结、一个特别巧妙的分类方式。这些“意外的好结果”往往包含了有价值的提示词改进方向。

我的习惯是：遇到这种情况，立刻把输入和输出都保存下来，分析是什么提示词设计导致了这么好的结果。然后把这个发现应用到其他Skill上。这个习惯让我的Skill质量在三个月内提升了一个档次。

9. 关于Agent与Skill的关系，顺便聊几句

最近很多人都在讨论Agent，好像Agent是一个全新的东西。但在我看来，Agent本质上就是Skill组合的高级形态。

一个Agent，拆开来看，就是一组Skill加上一个编排层。编排层负责决定什么时候调用哪个Skill、怎么传递参数、怎么处理异常。Skill负责执行具体的任务。你把我前面讲的Skill组合玩明白了，再去看Agent框架，会发现底层逻辑是相通的。

所以我的建议是：不要一上来就搞Agent，先把Skill组合玩透。Skill组合是基本功，Agent是进阶。基本功不扎实，直接上Agent，大概率是搭了一个跑不通的花架子。

另外，关于“Agent安全”这个话题，我的看法是：在个人工作台阶段，安全风险主要来自两个方面——一是敏感数据不小心被发送到外部服务，二是自动执行的操作超出了预期范围。对于第一点，我的做法是在预处理Skill里加一个“敏感信息检测”步骤，发现敏感内容就标记出来，由我决定是否继续。对于第二点，我的做法是给所有“写操作”类的Skill加上确认环节，不自动执行，等我确认后再跑。

这些做法不复杂，但能避免很多麻烦。毕竟，工作台是为你服务的，不是给你添乱的。