不谈理想谈落地：腾讯云 AI Skills 是怎么把一个“全能 Agent”从口号变成现实的
这段时间我几乎把所有业余时间都砸在了 Agent 项目上。AI Skills 这个概念挺早就看到了，但真正动手去写、去调、去跑通一套完整流程，还是在腾讯云上注册完账号、把环境折腾利索之后。折腾完我最大的感受是：Agent 的能力上限真不在模型，而在你肯不肯花心思把工具、记忆、编排这些底层的活儿做扎实。
这篇文章我不打算聊那些高高在上的架构理论，就实打实地讲讲我在腾讯云上从零搭一个带 Skills 的 Agent 踩过的路：为什么 Skill 是 Agent 的关键底座、它和 Agent 本体到底怎么分工、怎么写一个能稳定复用的 Skill、再配上完整的调试流程和排坑记录。看完你至少能少走我一半的弯路。
如果你是刚接触 Agent 开发、对“Agent 框架”“AI Skills 怎么写”还停留在概念层的朋友，这篇文章尤其适合你。我会尽量把每一步背后的逻辑讲透，不是只给你一堆命令和配置。
1. 为什么我盯上了 AI Skills 这套东西
1.1 纯靠“对话”撑不起真正的 Agent
先说个反直觉的事：很多人觉得 Agent 就是“能聊天的机器人”，给它一个模型 API，配上一段 system prompt，就能自动规划、自动调用工具。早期我确实也这么干过，结果开发了两周，产品一上线就露馅——只要任务稍微复杂一点，模型就会在各种细节上翻车：忘了一个参数、调错了一个接口、中途断了上下文，整个任务就废了。
问题出在哪？模型本身再聪明，它也不是一个稳定的“业务系统”。它没有严格定义“什么步骤可以做什么”、没有约束自己“只能在什么条件下调用什么工具”，更没有一个统一的标准去规范一次任务的输入输出。本质上，大语言模型擅长的是“理解”和“生成”，而不是“执行流程”。让模型裸奔着去完成任务，就像让一个实习生没有任何操作手册就上手操作生产系统——灵感来了能出彩，可大部分时候是在试错。
AI Skills 解决的恰恰是这个问题。它不是替代 Agent，而是给 Agent 装上“技能包”：把一套可复用的流程、工具调用方式、输入输出规范、异常处理逻辑打包成一个独立的模块。Agent 遇到对应场景时直接加载这个 Skill，而不是每次都在对话里现想。
1.2 腾讯云 AI Skills 解决的核心矛盾：可复用与可管控
市面上的 Agent 项目很多，但大多数卡在“单机自嗨”阶段：代码写死了、工具绑死了、换一个项目全得重构。腾讯云这套 AI Skills 吸引我的地方在于，它是把“技能”当作一个独立的云上资产来管理：
- Skill 独立于 Agent 存在。你在一个 Agent 里写好一个 Skill，另一个 Agent 也能直接引用，不需要复制粘贴代码。
- 有标准的执行上下文。腾讯云把 Agent 和 Skill 之间的交互方式做成了规范：哪些参数是输入、哪些是输出、工具调用的结果怎么回传，都有一套约定。
- 能配合云端资源和工具。可以接入你的云函数、API 网关、对象存储等腾讯云能力，Agent 的执行链路和基础设施是可以打通在一起的。
这一点对生产环境特别重要。因为 Agent 一旦要面向真实用户，就不能只是“有一个模型”那么简单，你得考虑并发、鉴权、限流、可观测性，甚至要考虑技能版本迭代。AI Skills 这个模式相当于把“技能”变成了一个可以上线的服务，而 Agent 只是技能的调度者。
2. 先理清一件事：Skill 和 Agent 到底差在哪
2.1 类比理解：Agent 是员工，Skill 是岗位能力
我在各类技术社区里经常看到有人把 Skill 和 Agent 混为一谈，这俩概念确实容易绕晕。我自己的理解很朴素：Agent 是“执行者”，Skill 是“执行能力”。
你可以把 Agent 想象成公司里的一名员工，Skill 是他掌握的一个个岗位技能。员工可以同时掌握好几个技能：会写周报、会做数据分析、会发邮件。但技能本身是独立于员工存在的，换一个人来，只要他有这个技能，同一件事照样能办。AI Skills 里的“技能”就是这个独立的岗位技能，Agent 只是那个“会调用技能的人”。
试想一下：如果你把所有能力塞在 Agent 的提示词里，那 Agent 换一个就得全部重新写一遍；而且模型很容易在多个能力之间互相干扰。把能力拆成独立的 Skill 之后，Agent 本身变得很薄，它只需要负责理解和调度，真正干活的是 Skill。
2.2 两者的边界：调度与执行的分工
从工程实现的角度看，边界更清晰：
- Agent 的职责：理解用户意图、拆解任务、决定调用哪个 Skill、把多个 Skill 串成一条工作流、维护对话状态和记忆。
- Skill 的职责：完成一个具体、明确、可测试的子任务。比如“查询订单状态”“生成一份周报”“把文本翻译成英文”这类，输入是什么、输出是什么、中间调用哪些 API，全部在 Skill 内部定义清楚。
当一个任务比较复杂时，Agent 就像一个项目经理，把大任务拆成几个小任务，再分别交给各个 Skill 去执行。Skill 之间最好不互相依赖，这样每个 Skill 都能独立测试、独立升级。我在实际开发中的原则是：一个 Skill 只做一件事，宁可多拆几个，也不要写一个“万能”的 Skill。
2.3 Skill 和 Agent 的协作方式
在腾讯云 AI Skills 的实践里，Agent 和 Skill 的协作通常遵循这样一个流程：
- Agent 收到用户请求，先做意图识别。
- 根据意图匹配对应的 Skill，把用户请求里的关键参数抽出来，填进 Skill 的输入字段。
- 触发 Skill 执行，Skill 内部会调用预设的工具/API/云函数来完成具体操作。
- 执行结果返回给 Agent，Agent 再把结果转成自然语言回复给用户。
这中间最需要花心思的地方，就是“参数抽取”和“结果回传”。如果 Skill 的输入输出定义不清晰，Agent 大概率会把参数抽错或者回传结果组织得乱七八糟。这里我的建议是：每个 Skill 都要有明确的 schema，字段名要有语义，必填项和默认值要写清楚，最好还要有校验逻辑。
3. 手把手：在腾讯云上从零搭一个带 AI Skills 的 Agent
3.1 前置准备：账号、环境、CLI 工具链
要动手实践，首先得把基础环境搞定。这一步看似简单，实际上坑不少。说说我的具体操作流程：
- 注册并完成实名认证。腾讯云的 Agent 开发服务需要实名认证，这一步绕不开。如果你是个人开发者，用个人认证就行；如果是公司项目，建议直接企业认证，后面涉及到云函数、API 网关等资源时权限更顺。注册时有任何环境异常提示，先检查网络环境和浏览器模式，换个无痕窗口往往能解决。
- 开通 AI 相关服务。在控制台找到 Agent 开发/AI Skills 相关入口，按引导开通。这里要注意，不同地域支持的模型和功能可能有差异，我默认选的上海地域，整体功能比较全。
- 安装并配置命令行工具。如果你想走 Infrastructure as Code 的路线，腾讯云的 CLI 工具（tccli）可以帮上大忙。安装很简单，用 pip 就能装：
pip install tccli tccli configure配置时需要填 SecretId 和 SecretKey，这俩在控制台的“访问管理-API 密钥管理”里生成。我给的建议是：别用主账号密钥，建一个子账号、只授予必要的权限，安全第一。
- 准备好你的模型服务或 API。AI Skills 的执行需要模型驱动。我的方案是先用云上托管的模型服务，把 API Key 配好再开始写 Skill。如果你有自己的模型服务，只要服务地址能公网访问，也可以接进来。
3.2 把需求拆成可落地的 Skill 结构
环境准备好以后，先别急着敲代码。我见过太多人一上来就写 Skill，写到一半发现需求理解偏了，又推倒重来。我自己总结的流程是：
第一步：定义场景。想清楚你的 Agent 要解决什么问题。我拿自己最近做的一个“内容自动发布助手”举例，它有四个核心场景：文章摘要生成、标题优化、关键词提取、一键发布到内容平台。
第二步：拆分 Skill。把每个场景进一步拆成独立的 Skill。如果发现一个场景涉及多个工具调用，那就拆成多个 Skill，再用 Agent 的工作流串联起来。
第三步：定义输入输出。这是最容易偷懒却最不能偷懒的一步。我通常会给每个 Skill 建一张小表，把参数名、类型、是否必填、默认值、说明写清楚。这张表会直接映射到代码里的 schema，越清晰后面调试越省事。
以“标题优化”这个 Skill 为例，输入就是“原始标题”和“平台类型”，输出就是“优化后的标题列表”。就两个字段，看似简单，但如果你不做规范化，等实际对接模型的时候就会遇到“模型自由发挥”的问题——它给你编一个不存在的平台类型，或者把事情搞复杂。
第四步：评估复用性。写 Skill 之前问自己一句：这个能力换一个 Agent 还需要吗？如果答案是“会”，那这个 Skill 就值得独立出来。比如“关键词提取”就很通用，不管哪个 Agent 都可能用到；而“一键发布到某个具体平台”就相对专用，可以做成独立的发布器。
3.3 从一个最小 Skill 开始：代码示例与逐行解释
先来一个最简单的 Skill 示例，功能是把传入的文本做摘要提取。用这类小例子把流程跑通，后面扩展就轻松了。
# title_summarizer.py # 一个最小可用的 AI Skills 示例：文本摘要提取 from skills_registry import BaseSkill, SkillInput, SkillOutput class TitleSummarizerSkill(BaseSkill): name = "title_summarizer" description = "摘要提取：给一段长文本，返回简洁的摘要结果" version = "1.0.0" def __init__(self): super().__init__() self.model = self.load_model("chat_model") # 从配置加载模型 def input_schema(self): return SkillInput( fields=[ {"name": "text", "type": "string", "required": True, "description": "需要做摘要的原始文本"}, {"name": "max_length", "type": "integer", "required": False, "default": 200, "description": "摘要最大长度"}, ] ) def output_schema(self): return SkillOutput( fields=[ {"name": "summary", "type": "string", "description": "生成的摘要文本"}, {"name": "used_model", "type": "string", "description": "实际使用的模型标识"}, ] ) def execute(self, text, max_length=200): prompt = f"请为以下文本生成摘要，控制在{max_length}字以内：\n{text}" result = self.model.chat(prompt) return { "summary": result.strip(), "used_model": self.model.model_id, }这段代码看着不长，但每个部分都有讲究：
name和description：Agent 会靠它来匹配 Skill，description 写得越具体，匹配越准确。别写“这是一个摘要工具”，要写“文章/报告/新闻文本的摘要提炼，适合内容创作场景”。input_schema()：定义输入，Agent 必须按这个格式传参。我的经验是：字段宁可少，但每个字段的语义必须精确。output_schema()：定义输出。这里我习惯把模型标识也带出来，后面排查时好用。execute()：真正的执行逻辑。这里直接拿着 prompt 去调模型，简单粗暴，但已经是一个能跑的 Skill 了。
3.4 如何让 Skill 的“输入 schema”不拖垮 Agent
刚才提到 schema 很重要，但我实际用下来，很多初学 Agent 开发的读者会在 schema 上吃大亏。这里展开说说：
首先，不要用一句话把所有输入糊在一起。有些教程喜欢把参数都塞进一个input字段，Agent 生成时确实不用纠结字段名了，但代价是你把理解成本全压给了模型。比如：
{ "input_vars": { "text": "阿里云发布了一款新芯片，性能提升50%...", "platform": "tech" } }这种写法看着简单，但一个 Skill 如果输入太复杂、嵌套太深，Agent 在执行时很容易抽错层级，甚至把一个对象整个传成字符串。我在实践中更倾向扁平化、少嵌套的 schema，像这样：
{ "text": "阿里云发布了一款新芯片，性能提升50%...", "platform": "tech" }其次，必填字段越少越好。一个 Skill 如果能只用一个必填参数，就不要设计两个。因为 Agent 每多抽一个参数，就多一分抽错的风险。能靠默认值解决的、能靠模型自己从上下文推出来的，都别设成必填。
最后，字段命名要能“望文生义”。text、title、keywords、max_length这种一眼就懂；如果你起名tp、tl这种缩写，模型很可能会猜错你的意图。Skill 的 schema 本质上是你和 Agent 之间的接口协议，协议含糊，执行必乱。
4. 深入拆解：一条 Skill 从“能跑”到“能用”要过几道关
4.1 编写期：先用伪代码定流程，再补工程化代码
我在写第一个能跑通的 Skill 时走了一段弯路。当时直接照着需求写 Python，写到一半发现自己把模型调用、数据处理、日志全混在一个文件里，改一个逻辑就得翻半天代码。
后面我调整了方法：先用伪代码把执行流程写清楚，确认逻辑没问题，再写实际代码。以一个“自动内容发布” Skill 为例，伪代码大概是：
1. 接收参数：文章内容、目标平台、发布方式 2. 校验平台类型，不在支持列表内则直接返回错误信息 3. 根据平台类型选择对应的“平台适配器” 4. 调用平台适配器完成内容格式转换 5. 调用平台 API 发布内容 6. 记录发布结果（成功/失败/错误信息）并返回看到没有，伪代码阶段根本不涉及具体 API、不涉及模型 prompt，只是把“这个 Skill 要按什么顺序做什么事”理清楚。理清楚之后，再写代码就是水到渠成的事。
这种方法还有一个好处：当你需要和别人协作开发时，伪代码本身就是最好的设计文档。我在团队里推广这个方法之后，Skill 设计和开发之间的沟通成本降了不止一半。
4.2 调试期：没有标准输出的 Skill 不值得信任
Skill 写好之后，马上要做的是“单测式调试”。具体来说，就是准备一组典型输入，跑一遍，看输出是否符合预期。
我习惯给每个 Skill 准备 3 类测试用例：
- 正常输入：一个典型的、符合预期的输入，确认输出质量。
- 边界输入：空字符串、超长文本、缺少可选字段等，看 Skill 会不会崩。
- 非法输入：格式完全不对的输入，比如该传字符串却传了一个数组，看 Skill 能不能友好报错。
跑完测试后，我特别在意一件事：这个 Skill 的输出是否稳定。什么叫稳定？就是相同输入，多次执行的结果虽然不完全一样，但都在合理的波动范围内。如果同一个输入跑三次，三次输出差异巨大，那就说明 Skill 的 prompt 或参数设置有问题，得回去调。
调试时腾讯云控制台的日志功能必须用好。每次执行都要看三个东西：入参、调用的模型/工具链、最终输出。如果哪一步断了，日志里都会留下线索。我当时踩的一个坑是：Skill 已经部署上线了，但测试时一直报错，后来查日志发现是云函数的超时时间设太短，模型调用还没返回服务端就把请求掐了。
4.3 联调期：Agent 和 Skill 的“对齐”才是重头戏
Skill 单独跑通了，不等于和 Agent 配套就一定能成。这就像一个人的单项技能很厉害，但在团队里配合不好，照样出不了活。
联调时我重点测两个点：
第一个点：Agent 能不能正确路由到这个 Skill。给 Agent 一个自然语言请求，比如“帮我把这段新闻提炼一下重点”，看它是否调用到了标题摘要这个 Skill，还是跑去调用别的 Skill。如果路由不准，先检查 Skill 的 description 是否写得足够清楚；再看 Agent 的意图识别配置，是否把相近意图合并了。
第二个点：中间结果能不能平滑过渡。当 Agent 需要依次调用多个 Skill 时，第一个 Skill 的输出要能变成第二个 Skill 的输入。比如“内容助手”场景里，Agent 先做关键词提取，再把关键词用于标题生成。这两个 Skill 之间的字段是不是严格对齐的，直接决定了整条工作流能不能走通。
联调中我发现最常见的失败原因是字段名不一致：关键词提取 Skill 输出的是keywords_list，标题生成 Skill 要求的输入却是keywords，这一字之差就让流程在中间断开。现在我的做法是在项目层面做一份统一的字段字典，所有 Skill 都从这同一个字典里取名，彻底消灭这种“同名不同叫”的问题。
5. 从“单个技能”到“Agent 产业集群”：编排、记忆与安全
5.1 多 Skill 编排：工作流别写死在代码里
单个 Skill 是完成一个具体任务，但真正的应用场景往往是多个 Skill 按顺序或条件组合。在腾讯云的生态里，多 Skill 的组合方式比较灵活，我看到不少人直接在 Agent 的编排画布上拖拽连线，但这不等于说可以随心所欲地连。
我的编排原则很简单：
- 尽量线性，减少分支。分支多了，模型判断出错的概率就会累积。如果某种场景分支特别多，宁愿把它拆成多个更小的 Agent，每个 Agent 只处理一种路径。
- 把“确定性逻辑”放在编排里，把“开放性逻辑”留给模型。比如发布内容前要先检查是否登录、是否过期，这种判断是固定的，应该写到编排的流程控制里，不要指望模型自己“灵机一动”想起来。只有像“根据用户意图选择调用哪个 Skill”这种开放性判断，才交给模型。
深入一点说，所谓的确定性逻辑就是如果你有一堆适用规则是固定的，比如“购买了A类会员的用户可以享受折扣”之类，就不要让模型去推理，直接在流程里判断就好；而开放性逻辑是“帮我把这篇文章改得更有趣一点”这种没有唯一正确答案的，才适合模型发挥。
5.2 Agent 记忆：让 Skill 知道“之前发生了什么”
一个很现实的问题：Agent 执行多轮任务时，模型上下文窗口是有限的，Skill 之间总不能每次都把完整历史都带上，那样既费 token 又容易超出上下文限制。
我的实践是：在 Agent 层维护一个轻量的“记忆摘要”。每个 Skill 执行完后，只把关键信息回写到记忆里，比如“已经生成了3个标题候选”“用户选择了第二个”。下一个 Skill 执行时，只需要读取相关记忆片段，而不是拿全量对话记录。
这个“记忆摘要”的方案，本质上是对“长上下文”的一种工程化妥协。你也可以试试给 Agent 增加一个“工作笔记”的 Skill：每完成一个子任务，就自动把关键产出写到一个持久化存储里，等需要的时候再检索出来用。这样既不占用上下文，又不会丢关键信息。
5.3 Agent 安全：别让“万能”变成“失控”
Agent 能调用工具的能力越强，安全边界就越重要。我在做腾讯云 AI Skills 的时候，特别关注三个层面的安全问题：
第一，权限收敛。Skill 调用云资源时，不要给它授予“管理员”权限。比如一个只负责读取文件列表的 Skill，就只给它授予cos:GetBucket级别的权限，不要顺手把cos:PutObject也开了。这在云上做起来其实很方便，访问管理模块里按最小权限原则配置角色，然后把角色绑给 Skill 的执行身份就行。
第二，输入校验。所有外部流入 Skill 的输入，都要做合法性校验。尤其是如果 Skill 要拼接 SQL、拼接命令或拼接请求路径时，不要轻信模型抽取出来的参数。举一个常见风险：如果模型把用户输入里的换行符带进了命令拼接，攻击者是有机会注入额外指令的。我的习惯是，凡是需要传给系统命令或查询语句的参数，必须经过白名单校验或转义处理。
第三，执行熔断。给 Skill 执行设置超时和重试上限。Agent 内部出现死循环并不可怕，可怕的是没有熔断机制让它一直跑下去。我在设计 Skill 执行器时加了一道开关：单个 Skill 执行超过 30 秒自动终止，重试次数最多 2 次。成本账很好算，一次失控的多步调用，烧掉的 token 费和损耗的时间，可比开发时多写几行防御代码要心疼得多。
5.4 成本控制：优化模型调用次数
聊到 token 成本，这是 Agent 落地时一个绕不开的现实话题。模型调用太频繁、prompt 写太长，费用会蹭蹭涨。我实测下来，几种比较有效的优化手段包括：
- 把“判断型”请求从模型调用中剥离。比如判断输入是否合法、判断返回值是否为空，这类逻辑用代码直接处理，不要每次都用模型问一遍“请问这个输入合法吗”。
- 用小模型做大分类，用大模型做精生成。意图识别、关键词提取这类简单任务，完全可以用轻量模型完成；“写一篇深度分析”这种要求输出质量的，再用旗舰模型。腾讯云 AI Skills 支持按 Skill 配置不同的模型，这个功能我强烈建议用起来。
- 开启结果缓存。如果有一些固定输入的请求，比如“把文章标题翻译成英文”，而源文本在短时间内出现过，可以直接命中缓存，避免重复调用模型。实测在内容批量生成的场景里，效果很明显。
6. 实战复盘：我在腾讯云 AI Skills 上填过的五个大坑
6.1 坑一：Skill 描述写得太“文艺”，Agent 压根匹配不上
这是我一开始最容易犯的错。给 Skill 起描述时，我总想写得更“智能”一点，比如“文章摘要专家，提炼全文精华，用极简语言呈现”。理想中 Agent 应该秒懂，结果它经常把这个 Skill 推荐给“散文改写”场景。
后面我学了一个笨办法：站在 Agent 的角度去反推描述。Agent 做匹配时，靠的是用户输入和 Skill 描述之间的语义相似度。所以描述里务必带上任务动词和核心名词，比如“总结”“提炼”“摘要”“长文本”“新闻”“报告”。别用形容词堆砌，直接用用户可能会说的“话”来写描述。
6.2 坑二：把多个功能揉进一个 Skill，出了问题难排查
有一次我图省事，把“关键词提取”和“标题生成”都放进了同一个 Skill 里。结果用户反馈说“标题质量下降了”，我排查了整整一下午，最后发现是关键词提取步骤里改了 prompt，间接影响了标题生成的风格。
自那以后，我不再迷信“全能型 Skill”。一个 Skill 干一件事，听起来是不是很笨拙？但它带来的好处非常实际：调用链路短、测试粒度细、升级互不干扰。你把“多件事”的组合留给 Agent 去编排，而不是在 Skill 内部强行揉在一起。
6.3 坑三：忽略了幂等性，重复执行导致数据重复写入
Agent 执行任务时，网络闪断、模型超时都可能导致 Skill 被重新调用。如果 Skill 里有一个“写入数据库”的操作，重复调用就会产生两条一模一样的记录。
我的补救方案是：在需要写操作的 Skill 里引入request_id（请求唯一标识）。每次 Agent 下发任务时，生成一个全局唯一的request_id，Skill 在执行写操作前先检查这个request_id是否已经处理过，如果处理过直接跳过。这个思路对所有有副作用的操作都适用，项目上线前一定得检查一遍。
6.4 坑四：没有做“结果可解释性”，出了问题靠猜
Skill 执行完，如果只给 Agent 返回一个“成功”或者“失败”，后面排查问题时会非常痛苦。我现在的做法是：每个 Skill 在返回结果里附带上reason字段，说明这个结果是怎么来的；如果执行失败，则返回具体的错误码和错误详情。
比如发布失败时，返回结果不能只是{"status": "failed"}，而要具体写{"status": "failed", "error_code": "AUTH_EXPIRED", "detail": "目标平台登录凭证已过期，请重新授权"}。这样 Agent 才能把错误原因清晰反馈给用户，开发者也才能快速定位是哪个环节出了问题。
6.5 坑五：以为模型上下文越长越好，结果要么费钱要么失效
一部分 Agent 开发者有一个迷思：把上下文窗口开到最大，所有历史对话、工具结果、中间数据全塞进去，模型总该“看到”了吧。实测下来，超长上下文不仅成本高，还经常出现“久远信息被冲淡”的情况——模型不是看不到，是注意力被大量无关信息稀释了。
我的调整方案是：有用信息必须显式突出。比如在 prompt 里用“重要信息”标签单独把关键字段列出来，或者在编排流程中把核心数据放在 prompt 的最前最末位置。同时，及时清理无效的中间日志，该归档的归档，该截断的截断，让模型始终在一个干净、精简的上下文中工作。
7. 给正在入局 Agent 开发的同学的建议
踩完这些坑，我对 AI Skills 在腾讯云上的定位有了更清晰的认识：它不是替你把 Agent 写好，而是帮你把 Agent 里的“技能模块”工程化、可复用、可上线。真正决定你的 Agent 能不能用的，还是你对场景的理解、对 Skill 边界的划分，以及对各种异常情况的处理态度。
如果你想动手实践，我建议按这个顺序推进：
- 先跑通一个最小闭环。选一个最简单的场景，写一个最简的 Skill，接一个模型，让 Agent 能通过 Skill 完成任务。别一上来就搞复杂的编排。
- 再扩展 Skill 库。把你要做的场景逐个拆成 Skill，每个 Skill 都单独测试、单独上线。
- 最后做编排和记忆。当你有 3 个以上的 Skill 时，再考虑编排、记忆和复杂状态管理。过早优化反而会让项目陷在设计中出不来。
最后分享一个我自己的小技巧：给每个 Skill 都准备一个“说明书”文件，里面记录着它的设计目的、输入输出说明、测试用例和已知限制。这个文件不用给机器看，是给未来的自己看的。等你一个月后回来看这段代码时，会发现这份说明书比任何注释都值钱。
Agent 这条路要走得远，靠的不是某个模型有多聪明，而是你手里积攒的技能资产有多厚实。希望这篇实践笔记能帮你少踩几个坑，把更多精力放在真正有创造力的地方。
