芥末
发布于 2026-05-18 / 0 阅读
0
0

AI Agent Skill 开发指南:从 SKILL.md 到发布、评测与跨平台迁移

AI Agent(智能体)真正难用的地方,往往不是模型不会回答,而是每次都要重新解释背景、步骤、工具、边界条件和交付格式。Skill 解决的就是这个问题:把一套可复用的工作流写成结构化指令包,让 Agent 在合适的场景自动加载并执行。

Skill 不应该被理解成“替代人”的工具。它更像一个可复制的操作手册,适合接管重复、冗长、容易出错的任务;人仍然负责定义目标、判断结果、处理例外和决定是否发布到更大的范围。工程价值不在“把所有事交给 Agent”,而在“把稳定流程沉淀下来,让 Agent 少走弯路”。

Skill 是什么

Skill 是一个放在特定目录里的指令包,核心文件通常叫 SKILL.md。它告诉 Agent:

  • 什么场景需要启用这个 Skill;
  • 从用户输入里提取哪些信息;
  • 按什么步骤执行任务;
  • 需要调用哪些脚本、文档或外部资源;
  • 出错时应该如何处理。

可以把 Skill 理解成 Agent 的“技能卡”。Agent 平时只知道技能卡的名字和说明,真正需要执行任务时,才会读取完整说明和附加资源。

现实里的概念Skill 里的对应物
操作手册SKILL.md
手册封面标题和简介YAML front-matter 里的 namedescription
操作步骤Markdown 正文里的工作流
附录、模板、脚本references/assets/scripts/
员工按手册执行Agent 按 Skill 执行

一个最小 Skill 只需要一个文件:

my-skill/
└── SKILL.md

复杂 Skill 会带上脚本、参考资料和模板:

my-skill/
├── SKILL.md
├── scripts/
│   └── send.py
├── references/
│   ├── aliyun.md
│   └── aws.md
└── assets/
    └── template.md

Skill 的三级加载机制

Skill 的设计重点不是“把所有说明一次性塞给模型”,而是“让 Agent 按需读取”。大语言模型的上下文窗口有限,如果每个 Skill 都完整加载,很快就会把上下文挤满,还会增加误触发和指令冲突的概率。

典型加载过程可以分成三层:

flowchart TD
    A[用户提出任务] --> B[Agent 扫描所有 Skill 的 name 和 description]
    B --> C{是否匹配某个 Skill}
    C -- 否 --> D[按普通对话处理]
    C -- 是 --> E[加载对应 SKILL.md 正文]
    E --> F{执行中是否需要附加资源}
    F -- 否 --> G[按正文工作流执行]
    F -- 是 --> H[按需读取 references 或执行 scripts]
    H --> G
    G --> I[返回结果并说明关键步骤]

三层分别承担不同职责:

层级加载内容作用
第一级namedescription判断用户任务是否需要启用某个 Skill
第二级SKILL.md 正文提供执行步骤、参数、错误处理规则
第三级scripts/references/assets/处理确定性逻辑、长文档、模板和静态资源

这种设计有两个好处:Agent 平时只看很短的描述,不浪费上下文;任务复杂时又能逐步读取更细的资料,避免让主文件变成几千行的“万能提示词”。

安装和使用 Skill

不同平台对 Skill 的安装目录和市场形态不完全一样,但使用方式大致相同:获取 Skill 包,放到平台能识别的位置,重启或刷新 Agent 后生效。

常见渠道可以分成三类:

渠道适合场景使用方式
Skill 市场直接使用别人发布的 Skill搜索、安装、更新
ZIP 包离线分发或小范围试用下载后解压到指定目录
Git 仓库团队维护、版本管理、持续迭代clone 或软链到 Skill 目录

以 Aone Copilot 为例,手动安装时可以把 Skill 解压到用户级目录:

unzip my-skill.zip -d ~/.aone_copilot/skills/

如果是项目级 Skill,可以放到项目目录中,让它跟随代码仓库一起管理:

unzip my-skill.zip -d .skills/

使用内部 CLI(命令行界面)工具时,安装过程可以进一步简化。以 aone-kit 为例:

npm install -g @ali/aone-kit --registry=https://registry.anpm.alibaba-inc.com

安装某个 Skill:

aone-kit skill install <skill-name>

安装到指定目录:

aone-kit skill install <skill-name> --location ~/.aone_copilot/skills

全局安装:

aone-kit skill install <skill-name> --global

查看已安装 Skill:

aone-kit skill list

安装完成后,通常可以在 Agent 的 Skill 面板中看到新增项,也可以在输入框中通过平台提供的快捷方式唤起。不同平台可能叫法不同,但核心判断标准只有一个:Agent 是否能读取到对应目录下的 SKILL.md

创建第一个 Skill

一个 Skill 的核心是 SKILL.md。它由两部分组成:

  1. YAML front-matter:描述 Skill 的元信息和触发条件;
  2. Markdown 正文:写清楚 Agent 要怎么执行任务。

YAML front-matter

namedescription 是最关键的两个字段。前者是唯一标识,后者决定 Agent 什么时候触发这个 Skill。

---
name: dingtalk-webhook-skill
description: 通过钉钉自定义机器人 Webhook 发送群消息。当用户提到钉钉、机器人、webhook、群消息、通知、dingtalk、发消息时触发。
license: MIT
compatibility:
  - aone-copilot
  - claude-3.5+
metadata:
  version: 1.2.0
  category: communication
  tags:
    - dingtalk
    - webhook
    - notification
---

字段建议如下:

字段必需说明
nameSkill 唯一标识,建议只使用小写字母、数字和连字符,例如 dingtalk-webhook-skill
description触发描述,要写清“能做什么”和“什么场景该用”
license许可证,例如 MITApache-2.0
compatibility适配的平台、模型或 Agent
metadata.version语义化版本号,例如 1.2.0
metadata.category分类信息
metadata.tags标签数组,便于检索

description 不要写得太抽象。Agent 通常会保守触发,如果描述里缺少关键词,它可能不会使用本来应该使用的 Skill。

写法问题
发送钉钉消息的技能过于笼统,缺少触发场景
通过钉钉自定义机器人 Webhook 发送群消息。当用户提到钉钉、机器人、webhook、群消息、通知、dingtalk、发消息时触发。任务、工具和关键词都清楚

Markdown 正文

正文是给 Agent 的操作手册,建议固定包含这些部分:

模块作用
快速开始给 1 到 2 个用户输入示例,让 Agent 快速理解使用场景
参数列表说明需要哪些输入、是否必需、默认值是什么
工作流按步骤描述执行过程
错误处理列出常见异常和处理方式
附加资源告诉 Agent 何时读取 references/ 或执行 scripts/

一个完整的钉钉通知 Skill 可以这样写:

---
name: dingtalk-notifier
description: 通过钉钉机器人发送群消息通知。当用户提到“发钉钉消息”、“钉钉通知”、“群消息”、“webhook”时触发。
metadata:
  version: 1.0.0
  category: communication
  tags:
    - dingtalk
    - webhook
    - notification
---

# 钉钉群消息通知

通过钉钉自定义机器人 Webhook 发送群消息。

## 快速开始

用户输入示例:

> 帮我发一条钉钉消息到部署群,内容是:v2.1.0 已发布上线

## 参数列表

| 参数 | 必需 | 默认值 | 说明 |
|---|---|---|---|
| `webhook_url` | 是 | 无 | 钉钉机器人的 Webhook 地址 |
| `message` | 是 | 无 | 消息正文 |
| `msg_type` | 否 | `markdown` | 消息类型,支持 `text` 或 `markdown` |

## 工作流

### Step 1:解析参数

从用户输入中提取 `webhook_url`、`message` 和 `msg_type`。

缺少 `webhook_url` 或 `message` 时,不要猜测,向用户补充询问。

### Step 2:发送消息

调用本地脚本发送消息:

```bash
python3 scripts/send.py --url "$WEBHOOK_URL" --msg "$MESSAGE" --type markdown

不要在回复中泄露完整 Webhook 地址。

Step 3:确认结果

检查脚本返回的 JSON:

  • errcode0,说明发送成功;
  • errcode0,根据错误信息提示用户检查配置。

错误处理

错误处理方式
Webhook 地址缺失询问用户提供地址
token 无效提示用户检查 Webhook 是否复制完整
签名错误提示用户检查加签密钥或机器人安全设置
网络失败说明请求失败,并建议稍后重试

对应的脚本可以放在 `scripts/send.py`。确定性的网络请求、签名计算、格式转换都适合下沉到脚本里,避免让 Agent 每次临场拼代码。

```python
#!/usr/bin/env python3
import argparse
import json
import sys
import urllib.request


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--url", required=True)
    parser.add_argument("--msg", required=True)
    parser.add_argument("--type", default="markdown", choices=["text", "markdown"])
    args = parser.parse_args()

    if args.type == "text":
        payload = {
            "msgtype": "text",
            "text": {
                "content": args.msg
            }
        }
    else:
        payload = {
            "msgtype": "markdown",
            "markdown": {
                "title": "通知",
                "text": args.msg
            }
        }

    data = json.dumps(payload).encode("utf-8")
    request = urllib.request.Request(
        args.url,
        data=data,
        headers={"Content-Type": "application/json"},
        method="POST",
    )

    try:
        with urllib.request.urlopen(request, timeout=10) as response:
            body = response.read().decode("utf-8")
            print(body)
    except Exception as exc:
        print(json.dumps({"errcode": -1, "errmsg": str(exc)}, ensure_ascii=False))
        sys.exit(1)


if __name__ == "__main__":
    main()

脚本输出 JSON 到标准输出,Agent 就能稳定解析结果。成功时退出码为 0,失败时退出码非 0,这比让 Agent 根据一段自然语言猜测状态可靠得多。

写好 Skill 的四步

不要一上来就写流程。流程只是 Skill 的一部分,触发时机、输入输出和边界规则同样重要。

flowchart LR
    A[确定触发时机] --> B[确定输入与输出]
    B --> C[设计执行流程]
    C --> D[补充规则、错误处理和示例]

1. 确定触发时机

先写清用户在什么情况下会用到这个 Skill。触发词、常见表达、上下文条件都应该进入 description

例如工单处理 Skill:

description: 工单批量预处理技能。当用户提到“处理所有工单”、“排查所有工单”、“批量处理工单”、“我的工单有多少”、“帮我看看工单”时触发。

2. 确定输入与输出

Skill 需要哪些参数,最终产物是什么,都要提前定下来。输入输出不清楚,Agent 容易在执行过程中发散。

问题示例
必要输入是什么工单列表、项目 ID、时间范围
可选输入是什么优先级、负责人、过滤条件
输出是什么汇总表格、处理建议、变更 PR、通知消息
输出格式是什么Markdown 表格、JSON、代码补丁、命令执行结果

3. 设计执行流程

流程建议控制在 3 到 7 步。步骤太少,Agent 不知道怎么做;步骤太多,执行时容易丢失重点。

## 工作流

1. 从用户输入中提取项目 ID 和时间范围。
2. 查询目标时间范围内的工单列表。
3. 按状态、优先级和负责人分组。
4. 对高优先级未处理工单生成处理建议。
5. 输出 Markdown 汇总表格。
6. 对缺少负责人或信息不完整的工单单独列出。

4. 补充规则和错误处理

边界情况要写成明确规则,而不是依赖 Agent 自己猜。

## 规则

- 不要关闭用户没有明确授权关闭的工单。
- 缺少负责人时,只输出建议,不自动分配。
- 遇到接口超时,最多重试 2 次。
- 查询结果超过 200 条时,先输出分组摘要,再询问是否继续处理明细。

SKILL.md 的写作原则

Skill 写给 Agent 执行,不是写给人欣赏。表达越直接,执行越稳定。

原则推荐写法不推荐写法
用祈使句从用户输入中提取 webhook_url 参数。Agent 应该从用户输入中提取参数。
解释原因使用可见浏览器模式打开页面,因为目标站点会检测无头环境。必须使用可见浏览器模式。
控制篇幅主文件放核心流程,长资料放 references/把所有背景资料都塞进 SKILL.md
少绑定平台调用 shell 命令执行脚本。调用 Bash 工具执行脚本。
少硬编码示例写通用规则和参数只针对一个固定 case 写死流程

SKILL.md 超过几百行时,优先拆分:

cloud-deploy/
├── SKILL.md
└── references/
    ├── aliyun.md
    ├── aws.md
    └── azure.md

SKILL.md 只保留通用流程和选择逻辑。用户要求部署到阿里云时,Agent 再读取 references/aliyun.md;要求部署到 AWS 时,只读取 references/aws.md。这样能减少上下文污染。

脚本也要遵守几条工程规则:

建议原因
优先零依赖减少用户环境问题
提供降级方案Python 不可用时可退到 Node.js 或 Shell
输出结构化 JSON方便 Agent 解析
明确退出码Agent 能判断成功或失败
不打印敏感信息避免 token、密钥、Webhook 泄露

发布和管理 Skill

Skill 从写出来到被团队稳定使用,需要经历完整生命周期:

flowchart LR
    A[编写] --> B[测试]
    B --> C[代码评审]
    C --> D[发布]
    D --> E[安装]
    E --> F[使用反馈]
    F --> G[更新]
    G --> B

如果把 Skill 只当 Markdown 文档,发布会变得很随意;如果把 Skill 当成代码包,就会自然引入仓库治理、测试、版本、回滚和安全扫描。

发布方式

常见发布方式有两种:

方式适合场景优点注意点
Git 仓库发布团队长期维护方便代码评审、版本追踪、回滚发布分支、权限和流水线要统一
ZIP 包发布小范围试用、离线交付简单直接更新分发和版本追踪较弱

以 Aone 平台为例,Git 仓库发布更适合长期维护。创建 Skill 后平台生成仓库,本地开发完成后 push 到发布分支,再到平台发起发布。很多平台默认发布分支是 main,不要把仓库误初始化成 master 后再排查发布失败。

版本管理

Skill 没有版本,后续更新会很难追踪。建议至少维护三样东西:

my-skill/
├── SKILL.md
├── CHANGELOG.md
├── package.json
└── scripts/

metadata.version 使用语义化版本:

metadata:
  version: 1.3.0

版本号可以按这个规则更新:

变更类型示例版本变化
修复错误修正参数名、补充错误处理1.2.01.2.1
增加兼容能力新增一种消息格式1.2.01.3.0
破坏性变更删除旧参数、改变输出结构1.2.02.0.0

如果旧版本不再维护,可以在 description 或正文开头明确提示:

description: "[DEPRECATED] 旧版钉钉通知 Skill,请升级到 dingtalk-notifier v2。当用户仍调用旧版发送钉钉消息时,提示升级。"

这种做法能让已安装旧版的用户在触发时看到升级提醒。

跨平台 Skill 的兼容问题

不同 Agent 平台对工具名、路径、快捷命令和特殊语法的支持不同。一个 Skill 在 Aone Copilot 可用,不代表在 Claude Code、Cursor、Codex 或其他平台上行为一致。

常见污染有三类:

污染类型示例风险
平台语法污染@团队成员/cmd!bash不支持的平台会把它当普通文本,甚至误解含义
工具命名污染写死 BashWebFetchRead不同平台工具名不同,可能找不到工具
路径环境污染写死 ~/.claude/skills/ 或某个平台环境变量换平台后路径失效

跨平台写作可以遵守“三纯净”原则:

原则做法
正文纯文本不把平台专属触发符当通用指令
工具写能力写“调用 shell 命令执行脚本”,少写具体工具名
路径不写死使用相对路径或 <workspace> 这类占位符

确实需要平台专属能力时,可以用 HTML 注释隔离:

<!-- platform: accio-work -->
当任务需要团队协作时,使用 `@团队成员` 触发分配。
<!-- /platform -->

<!-- platform: aone-copilot -->
当任务需要工单流转时,使用 `/ticket assign` 命令。
<!-- /platform -->

<!-- platform: default -->
当任务需要分配时,输出“建议指派给:<候选人>”,由用户手动操作。
<!-- /platform -->

支持的平台可以按需渲染,不支持的平台通常会忽略注释内容。为了更稳,还要给每段平台特定逻辑准备默认降级方案。

发布前至少做三项检查:

检查项通过标准
跨平台冒烟测试至少在两个目标平台跑同一组输入,输出结构一致
降级路径平台专属能力不可用时,有替代方案
description 中性化除非 Skill 只服务某个平台,否则不要在触发描述里绑定平台名

最重要的兜底策略是把确定性逻辑放进 scripts/。只要目标平台能执行 shell 命令,Python、Node.js 或 Shell 脚本就能提供更稳定的结果,减少 Agent 在不同平台上“自由发挥”的空间。

把 Skill 当代码包治理

Skill 一旦被加载,就会影响 Agent 的行为;如果它还能调用工具、读写文件、执行命令,那它就不只是文档,而是带有执行能力的代码包。

团队级 Skill 建议引入这些门禁:

阶段做法
仓库治理保护 main 分支,合并必须走 PR(Pull Request,合并请求)
代码评审核心 SKILL.md 至少 1 人 CR(Code Review,代码评审)
自动校验CI(持续集成)运行 schema 校验、敏感词扫描、prompt lint
脚本测试scripts/ 目录必须有单元测试
回归评测每次变更跑固定用例,结果不能低于上一版
灰度发布支持 channel 时先发 beta,验证后升 stable
安全扫描检查注入风险、敏感信息、越权工具调用

一个简单的 CI 流程可以这样设计:

flowchart TD
    A[提交 PR] --> B[检查 SKILL.md 结构]
    B --> C[扫描敏感信息]
    C --> D[运行 scripts 单测]
    D --> E[执行 Skill 回归评测]
    E --> F{是否通过}
    F -- 否 --> G[阻止合并]
    F -- 是 --> H[允许合并]
    H --> I[发布 beta]
    I --> J[人工确认]
    J --> K[发布 stable]

Skill 的质量问题通常不是模型能力不足,而是缺少工程约束。没有评测用例,改动就无法比较;没有版本,用户就无法定位问题;没有安全扫描,指令注入和敏感信息泄露会迟早出现。

提高本地调试效率

创建 Skill 很快,慢的是调试循环。常见低效流程是:改一行 SKILL.md,让 Agent 重新加载,发现没生效,重启会话,再重新输入测试用例。小改动也可能耗费几分钟。

更合理的本地开发循环是:

flowchart LR
    A[编辑 SKILL.md] --> B[热加载或软链同步]
    B --> C[运行固定测试输入]
    C --> D[比较输出差异]
    D --> E{是否通过}
    E -- 否 --> A
    E -- 是 --> F[提交变更]

几种实用做法:

做法说明
热加载使用支持热加载的平台,修改后无需重启会话
软链开发把开发仓库软链到平台 Skill 目录
文件监听保存文件后自动跑校验和评测
评测驱动先写测试用例,再改 Skill
双会话对照一个会话加载开发版,一个会话加载稳定版,对比同一输入的输出

软链方式很适合本地开发:

# 在 Skill 仓库根目录执行
ln -s "$(pwd)" ~/.aone_copilot/skills/my-skill

这样编辑器里改的就是平台读取的目录,不需要反复复制文件。

可以再加一个简单的 watcher:

# 示例:文件变化时运行校验脚本
fswatch SKILL.md scripts references | while read file; do
  ./scripts/check-skill.sh
done

check-skill.sh 可以包含 front-matter 校验、敏感信息扫描和回归测试:

#!/usr/bin/env bash
set -euo pipefail

python3 scripts/validate-frontmatter.py SKILL.md
python3 scripts/scan-secrets.py .
python3 scripts/run-evals.py evals/

用评测驱动 Skill 迭代

Skill 的回归评测不需要一开始就做得很复杂。最小可用形式是一组输入和期望输出规则。

[
  {
    "name": "缺少 webhook 时询问用户",
    "input": "帮我发一条钉钉消息:部署完成",
    "expect": {
      "must_ask": ["webhook_url"],
      "must_not_contain": ["https://oapi.dingtalk.com/robot/send"]
    }
  },
  {
    "name": "正常发送消息",
    "input": "使用 webhook_url=*** 发送钉钉通知:v2.1.0 已上线",
    "expect": {
      "must_call_script": "scripts/send.py",
      "must_contain": ["发送结果"]
    }
  }
]

评测重点不是追求复杂指标,而是覆盖容易退化的场景:

场景为什么要测
缺少必需参数防止 Agent 瞎猜
敏感信息处理防止 token、密钥、Webhook 泄露
错误返回防止失败时仍报告成功
平台差异防止迁移后工具名或路径失效
输出格式防止表格、JSON、代码补丁结构漂移

当 Skill 每次修改后都能跑一遍固定用例,迭代就有了基准线。通过率下降时不要合入,避免为了修一个 case 破坏其他场景。

Skill 的自我进化要有护栏

更进一步的做法是让 Skill 记录自己的执行情况,并根据失败案例提出修改建议。这个方向很有用,但不能让 Agent 无限制改自己的规则,否则容易为了通过单个场景引入更大的冲突。

安全的闭环应该是这样:

flowchart TD
    A[执行 Skill] --> B[记录输入、输出和用户反馈]
    B --> C[Binary Eval 判断 pass 或 fail]
    C --> D{是否失败}
    D -- 否 --> E[归档成功样例]
    D -- 是 --> F[提炼失败原因和修复建议]
    F --> G[生成补丁 PR]
    G --> H[运行回归评测]
    H --> I{评测是否通过}
    I -- 否 --> J[拒绝修改]
    I -- 是 --> K[人工评审后合并]

Binary Eval 指二元评测,只判断 pass / fail。它比“打 1 到 5 分”更适合自动门禁,因为结果清晰,容易和 CI 流程结合。

可以在 SKILL.md 末尾加入元指令,但必须配合评测:

## 自我改进记录

每次执行完本 Skill 后:

1. 判断任务是否达成目标,只记录 `pass` 或 `fail`。
2. `fail` 时,在 `diary/YYYY-MM-DD.md` 追加失败案例、失败原因和修复建议。
3. 同一类修复建议在最近 3 次失败中重复出现时,生成修改 `SKILL.md` 的 PR。
4. 修改后必须通过 `evals/` 中的全部回归用例,未通过时不要合并。

再配一个执行日志脚本:

python3 scripts/log-execution.py \
  --skill dingtalk-notifier \
  --input "$USER_INPUT" \
  --output "$AGENT_OUTPUT" \
  --result fail

日志建议使用 JSONL(按行存储的 JSON)格式:

{"time":"2026-06-07T10:00:00+08:00","skill":"dingtalk-notifier","result":"fail","reason":"missing webhook was not requested"}

没有评测兜底的自我修改风险很高。Agent 可能把一次偶然失败写成永久规则,导致其他场景退化。更稳的策略是“记录失败 → 生成建议 → 跑评测 → 人工确认”。

用一个开发助手 Skill 管理完整闭环

当 Skill 数量变多,真正耗时的不只是写 SKILL.md,还有创建模板、迁移平台、跑评测、发布、批量更新和诊断问题。一个更高效的方式是把 Skill 开发流程本身也封装成 Skill,例如 skill-dev-aio 这种一站式开发助手。

它不应该替代人的判断,而是接管机械环节:

flowchart TD
    A[用户描述要做的 Skill] --> B[澄清触发场景和输入输出]
    B --> C[生成 SKILL.md 草稿]
    C --> D[生成 scripts 和 references]
    D --> E[生成 evals 回归用例]
    E --> F[运行本地评测]
    F --> G{是否通过}
    G -- 否 --> H[定位问题并修改]
    H --> F
    G -- 是 --> I[发布到目标平台]
    I --> J[记录版本和变更]
    J --> K[收集反馈并批量更新]

可以把能力拆成六块:

能力自动化内容人需要判断什么
快速创建 Skill生成目录、SKILL.md、示例和参数表目标是否定义准确
一键发布打包、提交仓库、触发平台发布是否允许发布到目标范围
优化评测根据失败用例调整描述和流程调整是否符合真实业务
检查诊断扫描格式、敏感信息、平台污染、缺失资源风险是否可接受
跨平台迁移改写工具名、路径和平台语法目标平台能力是否等价
批量更新修改多个 Skill 的版本、规则或依赖是否需要灰度和回滚方案

这种“用 Skill 开发 Skill”的模式,能把经验沉淀到工具里。人的主要工作变成定义需求、确认边界、审核结果和控制发布风险;Agent 负责把重复步骤跑稳。

常用资料入口

  • Agent Skills 规范与介绍:https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
  • Agent Skills 社区规范:https://agentskills.io/
  • skills.sh:https://www.skills.sh/
  • ClawHub:https://clawhub.ai/skills
  • SkillsMP:https://skillsmp.com/
  • Claude Code Plugin Marketplaces:https://code.claude.com/docs/en/plugin-marketplaces

Skill 开发的核心不是写一段更长的提示词,而是把可复用流程工程化:有清晰触发、有稳定执行、有脚本兜底、有评测门禁、有版本治理。做到这些,Agent 才能从“每次都要重新教”的聊天工具,变成能稳定复用经验的工作流执行器。


评论