【我在阿里拧螺丝3】淘天技术AI夜校培训思考——Agent、SKILL与模型
1. 前言
最近参加了淘天业务技术组织的 AI 夜校培训。因为我这段时间正好在做 Agent 开发相关的业务，所以报名参加了为期两个月的课程。上周四的第一场 Overview 讲得很好，我也想结合最近做 Agent 应用的经历，聊聊自己对 Agent、Skill 和模型的一些思考。
本文已经做过脱密处理，不涉及商业机密，个人思考的成分很高。部分章节默认读者了解 LLM 和 Agent 的基础概念，没有相关经验的话，读起来可能会稍微费劲一些。
2. Agent 可以代替一切吗？
从 2024 年 Agent 兴起，到 2025 年集中爆发，再到 2026 年随着 xxClaw 出现而引发“全民养虾”，LLM 加持下的 AI 仿佛什么都可以做。甚至有不少 AI 博主放出豪言：“未来没有软件，只有 AI。”
现实却没有这么整齐。很多人没有接触过 WorkBuddy、Manus、QwenWork 这类办公 Agent，对 AI 的认知仍然停留在和豆包对话的程度。即使办公 Agent 的月活真的从百万增长到亿级，AI 就能替代所有 SaaS 软件吗？
从软件工程的角度看，我觉得这个结论过于乐观。
LLM 可以粗略理解为一个规模极大的“成语接龙”系统。即使是顶级算法研究员，目前也很难对每一次输出做出清晰归因。调用 LLM 时，即使把 temperature 设为 0，多次返回也不一定完全相同。难以归因和输出不确定，是模型绕不开的特点。只靠模型能力，很难直接承担高敏感、高风险的业务操作。
LLM 真正带来变化的地方，是处理非结构化数据的能力。经过大量数据和参数训练后，它“看起来”几乎可以理解各种自然语言表达，并给出合理反馈。这恰好是传统结构化程序不擅长的部分。过去需要用户在多个界面里反复操作的流程，可以通过 LLM 改造成更自然的对话式交互，但这不等于原有软件会被完全替代。
在生产应用里，AI 和程序更像两个互补的角色。模型负责理解模糊意图、处理非结构化信息，程序负责确定性和结构化操作。一个最简单的例子是：生产环境通常会给 LLM 配一个计算器工具，让工具直接完成计算。模型当然也能算，但计算器的结果更稳定、更便宜，也更容易验证。
成本也是一个很现实的问题。Context 和 Token 都不便宜。一件确定性的事情交给普通程序处理，CPU 和内存消耗可能很低；如果每一步都交给 LLM，资源成本和响应时间都会明显增加。
当然，也可以更激进地想：如果确定性程序本身也由 AI 编写，并且写完就直接交给 AI 调用，是否意味着 AI 最终可以接管整个数字世界？某种意义上可以这样理解，但这个过程会很漫长。复杂软件架构和持续出现的增量需求，目前仍然很难完全自动化。
3. Agent 的本质是什么？
之前在即刻社区冲浪时，我看到不少昵称里带“xx_AI”的博主测评 DeepSeek、MiniMax、GLM 等新模型。有些人判断基模能力强不强，标准竟然是“开了多少个 Subagent”或者“能不能生成好看的视频”。后者至少还能对应模型的多模态能力，前者就很奇怪：开启多个 Subagent 本来是工程实现，和基模能力并不是一回事。
那么，什么是 Agent？Agent 和 Model 的区别又在哪里？
关于模型，可以参考我去年写的 LLM 入门文章。简单讲，模型的核心仍然像“成语接龙”：基于海量参数，通过向量和矩阵运算，把 Prompt Token 作为输入，再逐步生成输出。多模态模型的机制也类似，只是输入和输出变成了经过特殊编码的图片、音频或视频 Token。
看过 Codex、OpenCode 等开源 Agent 工具源码的人应该会发现，所谓 Agent，本质上是对模型 API 调用的一层工程封装。它把用户输入、工具和 Skill 的描述、系统信息等内容组装成上下文，传给模型 API；模型再逐字返回 Thinking Delta、Text Delta，以及要执行的工具名称和输入参数。
Agent 的价值，在于统一管理 LLM API 调用的运行时，并对外提供 ReAct、Handoff 等调用模式。开发者主要关注 Agent 的 Prompt、Tool Config 和 Skill，不需要反复适配下游模型接口的协议和参数。
再往外扩一层，现在的大型 Agent 平台的边界已经超过单个 Agent，更接近 Harness 套件。除了模型调用和上下文组装，它们还会处理记忆抽取与存储、状态恢复、工具执行，甚至自迭代优化。这些都属于 Harness 工程的一部分。
不过，开发者也没必要在所有场景里都服从 Agent 这层抽象。有时我们只想定制模型接口的某个参数，如果还要专门新建一套 Agent Prompt、Tool 和 Skill，多少有点“大炮打蚊子”。抽象应该解决复杂度，不能反过来制造复杂度。
很多基模会强调自己的 Agentic 能力。一个重要原因是：模型在训练阶段接触了大量 Function Call、Thinking Delta、JSON Schema、System Prompt 等格式的数据，所以它进入 Agent 环境后，更容易生成符合约定的工具调用信息。这类模型通常会被称为 Agentic Model。但工具编排方式、Subagent 数量和运行时恢复能力，仍然属于模型之外的工程系统。
4. 关于 Skill 的思考
今年年初，Anthropic 提出并带火 Skill 的概念后，很多朋友，尤其是不做开发的朋友，会觉得什么事情都可以写一个 Skill 解决。
我和产品同学交流时，经常会听到一句话：“快把这个东西抽成一个 Skill，以后我就不找你了。”这句话有对的部分，也有明显的边界。Skill 确实可以沉淀经验，但很多问题并不会因为写了一份 Skill 就自动解决。
如果了解 Agent 开发，就会知道 Skill 本质上是一套工作 SOP。为了避免模型上下文被撑爆，Skill 的内容通常会渐进式加载。因此，Skill 可以看成一个更大、更结构化的 Prompt。它和我们在豆包输入框里打出的指令，在本质上没有区别；差别主要在于它不会一开始就被全文塞进上下文，而是根据任务逐步加载，以节省上下文并减少对推理效果的干扰。
既然 Skill 描述的是一套 SOP，万物都可以 Skill 化吗？理论上可以，实际没有必要。
我们不应该为了 AI，把已有的 SOP 和 Workflow 全部重新包装成 Skill。一方面，程序化 Workflow 的执行成本很低，稳定性也更高；另一方面，同一份 Skill 放在不同 Agent 中，会受到上下文风格、基模能力和恢复机制的影响，结果很难像程序流程一样精确。Skill 的文本是确定的，执行结果却仍然带有模型的不确定性。目前市场上也缺少足够成熟、统一的 Skill 评估和优化工具，想要把 Skill 精准地规模化使用，还有很长的路要走。
另一个容易忽略的问题是，Skill 全文可以被 Agent 读取。开放一个 Skill，某种程度上等于把其中沉淀的经验全部暴露出来。对于包含敏感经验或内部知识的场景，这个风险不能忽略。
所以在多数确定性任务中，用 Skill 代替程序，往往只是“为了 AI 而 AI”。例如，把图片上传到 GitHub，可以直接写脚本调用 GitHub 接口，也可以写 Skill 让模型通过 Browser Use 操作页面。显然，脚本更快、更稳定，也更省心。
Skill 更适合难以完全程序化、但又能总结出操作经验的业务流程。它可以结合 MCP 和工具完成整体编排。譬如交接场景，即将离职的同学可以把操作手册整理成 Skill，接手的同学再借助 AI 完成过去需要反复询问的任务。这里的价值在于让隐性的经验变得可执行，确定性环节仍然交给程序。
还有一个更偏技术的问题：Subagent 和 Skill 到底有什么区别？对直接使用 WorkBuddy 等 Agent 工具的非技术同学来说，这个问题可能有些奇怪——Subagent 是一个 Agent，Skill 是 Agent 的一套 SOP，两者为什么要放在一起比较？
从工程实现看，Agent 和 Skill 最后都会变成一组传给模型接口的上下文。因此在实际开发中，经常会遇到同一个选择：一个任务究竟应该作为 Skill 放进主 Agent，还是单独交给一个 Subagent？
我的判断是，Subagent 更适合任务可以独立完成、需要独立上下文，或者能够并行执行的场景；主 Agent 加 Skill 更适合需要持续共享上下文的通用流程。使用 Subagent 时，还要特别注意 Handoff 过程里的中间产物如何转交，否则上下文隔离带来的好处，很可能会变成信息丢失。
5. Agent 的常见业务场景
讨论到这里可以看到，Agent 很难替代软件完成所有工作；有了 Agent，也不意味着业务营收和利润会自然增长。
Agent 首先是一种提高效率的工具。它可以帮助程序员完成从需求理解到代码实现的端到端开发，也可以帮助非技术同学排查工单、处理 Excel、写周报。更重要的是，其中很多事情能够并行执行。标准化程度较高、但处理过程复杂的工作可以交给 Agent，人则把精力留给需要判断和创造的部分。
因为能处理大量非结构化数据，Agent 也天然适合客服、销售和 QA，新人 Landing、工作交接同样是常见场景。我之前在 WAIC 上看到，金融系统几乎都在尝试基于 Agent 做答疑客服。听起来这些实践还比较早期，但方向很直观：先把分散的知识和操作流程串起来，再逐步提高任务完成度。
学习也是一个很适合 Agent 的场景。Agent 不会因为重复提问失去耐心，可以按学习者的理解程度调整讲解方式，知识覆盖面也足够广。不过，知识准确性和教学节奏仍然需要评测，尤其是在专业领域里，不能因为回答流畅就默认它是对的。
再往算法方向看，还可以用 LLM 推理做更细致的用户需求理解，补充传统结构化特征难以表达的信息，从而形成更精细的用户画像，再作用于搜索和推荐场景。
目前看来，大部分 Agent 场景更确定的价值仍然是效率提升。希望靠 AI 直接缓解全部业务压力的团队，可能需要先重新审视业务模式，看看问题究竟来自重复劳动、信息处理，还是产品本身。把所有期待都压在 AI 上，很容易错过真正应该解决的问题。
6. Agent 开发的选型和注意点
对技术同学来说，很多特定业务无法直接通过 WorkBuddy、QwenWork 等通用桌面 Agent 完成，往往还是要调用模型厂商的接口，自行管理上下文。在这个场景下，有几件事需要优先想清楚。
首先是 Agent 运行在用户本地还是云端。本地运行时，消息断连和服务恢复相对简单；如果运行在云端，就要处理消息断联、服务器重启、系统宕机、上下文存储和场景记忆等异常情况。云端也有明显优势：可以统一收敛用户数据，并且 7×24 小时执行业务。很多厂商已经意识到这一点，阿里之前的 MuleRun、Qoder Agent Cloud 等产品，都是把 Agent 封装到云端，再让用户通过 API 调用。
其次是 ReAct 和 Workflow 的选择。现在的通用 Agent 几乎都有 ReAct 的影子，也出现了 Codex（OpenAI 也开源了同名框架）、DeepSeek Harness、AgentScope 等实现。ReAct 通过“思考—行动—观察”让模型自主调用工具，适合解决开放问题；但很多时候只有 ReAct 还不够，开发者仍然要提供更确定的 Workflow。
Workflow 的优势是确定性高、成本更可控、执行速度更快。一种常见做法是让 ReAct 先生成 Dynamic Workflow，由 AI 决定流程，再交给程序完成执行。常见的 Plan 模式也可以看成这种形态的变体。实际选型时，需要把“由模型判断什么”和“由程序保证什么”明确拆开。
真正写 Agent 时，上下文管理、记忆和缓存也很重要。用户消息和系统消息如何定位与插入？什么时候抽取用户记忆？记忆存在哪里、如何召回？怎样组装上下文才能更好地利用 Model Cache？工具输入输出如何压缩？每次会话又应该如何管理？这些问题很难靠一个统一框架全部解决，往往要结合产品形态逐个设计。这里先把问题列出来，具体方案以后有机会再展开。
最后，开发 Agent 应用不要拘泥于 Chat。用了聊天框不等于产品就更智能。Agent 真正擅长的是处理非结构化信息和理解模糊意图，交互方式仍然要从产品视角出发：明明一个按钮就能解决的事情，为什么一定要让用户输入一段话？
7. 如何做 Agent 评测
在传统软件工程中，开发和测试是两个重要环节；Agent 开发同样离不开评测。验证 Agent 能否完成基本功能只是第一步。更困难的问题是：它在非结构化场景里究竟好不好用、能不能稳定使用、是否值得使用，Bad Case 如何发现，出现问题后又怎样快速定位和优化。
我觉得 Agent 评测至少要解决三个问题：
- 基础功能：保证 Agent 的产品功能满足业务诉求。
- 稳定性：覆盖不同输入、不同时间和各种 Bad Case，检查输出是否持续符合预期。LLM 的输出带有概率性，评测不能只依赖一次人工体验，因此 Agent 评测需要尽可能自动化。
- 优化建议：评测结果除了说明 Agent 是否符合预期，还要结合执行链路定位可以优化的位置，例如 Prompt、Cache 命中率、Skill 或工具描述。最好还能评估单次执行成本，用来判断真实 ROI 是否满足业务预期。
要做到这些，评测体系还需要几类基础能力：
第一，采集 cache hit rate、TTFT、token cost、time cost 等运行指标。没有这些数据，很难判断一次优化究竟改善了效果，还是只增加了成本。
第二，围绕业务预期设计评测标准。Agent 输出很难只用一个通用分数衡量，评测项必须能回答它是否完成了具体业务目标。
第三，识别和定位 Bad Case。发现结果不符合预期之后，还要继续判断问题出在 Prompt、Skill、工具、上下文组装，还是模型本身。
第四，沉淀历史评测结果，让每一次改动都能回溯，并和之前的版本关联。否则 Prompt 或 Skill 调整后，很容易只修好眼前的 Case，却把旧问题重新带回来。
这部分我目前更多是在总结问题和方向，具体的评测实现还没有在本文里展开。等后续实践更完整，再单独写一篇。