橘子今天吃饭了没最近在搭自己的 Agent 工作台时，我发现一个特别现实的问题：模型能力再强，如果缺少能跑通具体业务流程的 Skill，它就仍然只是一个聊天窗口。为了把“Agent Skill 到底该怎么设计”这件事搞清楚，我拿知乎问答场景做了一个从 0 到 1 的实验，实现了一个自动回答 Skill 原型。
这个 Skill 做的事情很聚焦：把问题采集、筛选、上下文检索、回答生成、草稿导出让 Agent 串成一条完整链路，整个过程不碰线上发布，也不批量制造内容，纯粹用于研究一套 Skill 应该如何被定义、拆分、实现和验证。如果你正在学 Agent 开发，或者想弄懂一个标准 Skill 包的内部结构，这篇教程可以直接照着手写一遍。
先说清楚：这不是一个“无人值守刷回答”的工程，我也不会教你怎么绕过平台的风控和规则。文章里的所有设计都把“人工复核”放在最关键的位置上，默认只输出本地草稿。
1. 先划定边界：这个Skill实验能做什么、不能做什么
很多人在群里看到“自动回答”四个字，第一反应是：是不是可以挂机刷赞涨粉？我的答案是，如果你奔着这个目的去，这个项目从一开始就走偏了。我做这个 Skill 的核心动机是想回答一个工程问题：当 Agent 需要完成一个多步骤、强领域性、且有外部平台依赖的任务时，如何把任务拆成可被模型调用的能力模块。
所以这个 Skill 的实验结果是“一份完整可运行的代码”和“一套可复用的 Skill 设计思路”，不是“一个可以直接部署上线赚钱的工具”。
1.1 这个Skill解决的，并不是“无人值守刷号”
技能不等于自动化机器。一个 Skill 在 Agent 生态里的定位，是把某个领域的专业流程固化成可调用的能力。拿知乎回答来说，人类答主在动笔之前会做这些事：看问题描述、判断自己有没有相关经验、回忆或搜索资料、组织语言、区分观点和事实、决定要不要发布。
自动回答 Skill 要把这些环节都抽象出来，交给 Agent 调度。这个过程的难点不在于“让大模型写一篇回答”，而在于“让生成结果的每一步都有依据、可回退、可复核”。
我做实验时定了三条铁律：
- 所有生成结果只写入本地文件或数据库，不调用任何线上发布接口。
- 上下文来源必须保留出处，没有出处的关键事实宁可不说。
- 每条回答生成后必须经过一次“风险检查”，发现可能误导用户的内容直接打标。
这三条不是畏手畏脚，而是负责任地做 Agent 开发的基本功。如果你把 Skill 接到别的场景，比如写邮件、写周报、分析数据，这些原则同样成立。
1.2 合规红线：哪些不能碰，哪些能用来做研究
知乎有自己明确的平台规则，批量自动发布、绕过反爬机制等都是违规甚至违法的行为。我在下面列了这张红线表，建议每个做类似实验的朋友都存一份：
| 不能做（红线） | 为什么会被界定为风险行为 | 研究场景的正确做法 |
|---|---|---|
| 自动发布回答到线上账号 | 违反平台规则，有封号和法律责任风险 | 输出到本地 Markdown 文件 |
| 使用无头浏览器模拟真人、绕过验证码 | 破坏平台安全机制，属于典型恶意访问 | 不使用任何绕过手段，只用人工授权的小批量数据 |
| 高频请求、接口轮询、大量采集问题 | 可能构成不正当竞争或侵犯数据权益 | 手动导入文本，或使用自己收藏夹的离线快照 |
| 生成内容冒充真人牟利 | 涉嫌虚假宣传、欺诈，影响平台内容生态 | 明确标注“AI生成草稿，仅供研究” |
我的建议是，你在任何平台做自动化实验之前，先花十分钟把服务协议读一遍，再把“我的方案会不会让别人觉得被欺骗”这个问题想清楚。这个习惯比任何技术选型都重要。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体链路设计：Agent怎么把“回答知乎问题”拆成可控步骤
很多人一上来就写代码调用大模型，结果做到一半发现逻辑混乱，改来改去。我这次的做法是先画链路图，把所有环节拆开，再逐个实现。虽然我已经注意到很多教程喜欢用 Mermaid 画图，但我觉得用文字描述更清楚，尤其是你要把这个 Skill 移植到别的 Agent 框架时，文字清单比图片更容易写进代码。
2.1 从问题输入到草稿输出
整个 Skill 的调用链路被我拆成了六个阶段：
- 输入模块：接收一个问题文本、一个待回答清单，或者从本地文件读取一批历史问题。
- 预处理：清洗噪声文本，过滤掉明显不适合自动回答的问题。
- 上下文模块：从本地笔记、知识库或人工提供的资料中检索和问题相关的内容。
- 生成模块：构造提示词，调用大模型生成回答草稿。
- 后处理：对草稿做事实检查、风险标记、长度控制。
- 输出模块：把草稿写成 Markdown 文件，并记录任务状态。
这个设计最关键的地方在于“上下文模块”和“后处理”不是可选项。如果只是让大模型自由发挥，那根本不需要 Skill，一个 Prompt 就能解决。Skill 的价值就在于它有强制执行的流程，可以保证每次输出的质量下限。
2.2 Skill参数与运行模式
我想让这个 Skill 被 Agent 调用时足够“听话”，所以把它的对外接口设计成了参数化形式。Agent 调用它时，只需要知道四个参数：
- question：问题文本，必填。
- style：回答风格，可选值有 objective（客观分析）、story（亲身经历）、professional（专业解答）、simple（通俗解释）。
- max_length：最大字数限制，默认 800。
- with_evidence：是否强制要求引用材料，默认 true。
内部还有一个隐藏参数“mode”，取值范围是 draft 和 preview。draft 模式会把结果写入本地文件，preview 模式只在终端打印前 300 字用于快速验证。默认永远是 draft。
这个设计思路是从 Anthropic 的 Skill 规范里学来的：一个 Skill 包应该包含描述、输入参数、操作