经管之家App
让优质教育人人可得
立即打开
自 Anthropic 在 25 年 11 月发布 Agent Skills 以来，公司内外已是“漫山遍野”的分析文章与 Demo，几乎卷到了全无视角的程度。去年 12 月，我还专门在我们部门《洞察月刊》里开了两个专栏来拆解它。短短两个月，GitHub 上开源的 Skills 堆积如山（夸张修辞），各大框架纷纷宣称原生支持，不少项目已经落地。
从Anthropic 在25年11月对外发布Agent Skills之后，公司内外都有大量的洞察、分析文章或Demo，各种角度几乎无视角，我在12月份我们部门的《洞察月刊》中还专门针对Agent Skills做过两个栏目的深入分析。而且短短2个月，已经有大量的开源共享的Skills在GitHub上出现了，很多框架和组件也都宣称支持了，公司内外已经有不少AI Agent都已经使用了Skills。茶思屋的小编问我有没有兴趣发表一个关于Skills的时候，对于一个已经开始规模落地的技术，现在让我写，本也写不出来个啥了，反正小编估计也就是散个网，运营一下，也没有当真，10个受约人里面有1个发帖也行，也就是完成个KPI，活跃一下社区就可以了。
但最近，我脑子里始终挥之不去一个哲学命题：到底 LLM-Based Agent 是对传统的颠覆，还是延续？ 那些不断涌现的、为 Agent 服务的工程技术，到底是科技界的“刻舟求剑”，还是在顺应某种新范式？
我想借 Skills 作为一个切片，聊聊我这段时间对 Agent 开发范式迁徙的“认证历程”。读后感可能是：奔着标题是Agent Skills来的，实际全是“正确的废话”。哈哈
随着Agent在公司很多领域落地，为了提升准确率，理解华为，理解所服务的华为的某个领域，往往会上很多手段，语义，图谱，知识，最终都塞到Prompt中，类比就是给一个新员工一份长达1000多页的员工手册（夸张举例），并要求这个员工能够倒背如流并立马处理所有模糊的输入和请求。虽然Agent不会奔溃，但是Token消耗激增，且越长的指令，Agent大概率会产生“漂移”、“胡言乱语”。
当然业界也有好些技术，在解决这些问题，直到Anthropic Agent Skills推出，它为Agent提供了模块化，渐进加载，按需加载的“技能包”机制，每个技能包含：
me tadata（元数据）：让 Agent 知道自己“能干什么”。
Instructions（SKILL.md）：定义决策逻辑的“灵魂”。
sc ripts/Resources（代码与资源）：提供确定性执行的“肌肉”。
对于我这种伴随着经典软件工程成长、认知几乎固化的人来说，第一反应是：太对了，这才是“正统”！ 它完美契合了沉淀几十年的这一代软件架构和软件工程的最佳实践：版本控制、模块化、可复用、确定性。
对比一下那些暴露年龄的概念，你就能理解这种“亲切感”（如下类比从专业严谨角度肯定有瑕疵哈）：
Skills 与 DLL（动态链接库）/ NPM：逻辑上何其神似？？
文件件系统化：天生适配 Git 版本控制、CI/CD 和沙箱运行；
按需加载与解耦：这不就是微服务（Microservices）的思路在 AI 时代的投射吗；
当时我觉得，Skills 代表着 LLM 开发再次被拉回了“工程正统”。用个不恰当的比喻，大模型像是穿着卫衣、酷炫但不羁的Geeker，而 Skills 给它穿上了一套合体的西装。 它用“旧枷锁”约束出了 AI 在企业内部落地的“新自由”。
不敢完全相信LLM的推理，那我就要求Agent必须调用某个Python脚本；
不放心大模型的黑盒推理，我有实实在在文件系统承载的的Skills，我可以提交到Git库，我可以Code Review，我可以回滚版本，我甚至可以为某个Skills写单元测试用例，
不喜欢Prompt的“未知感”和“上帝感”和“密密麻麻的复杂感”，有了Skills，不需要看到几万Token的Prompt而焦虑了，我们可以把Skills结构化，可分可合，粒度可大可小，按需加载，这才是软件经验解决复杂系统的真理啊。
然而，随着各种实践和我所在的部门的一些相关工作的展开，我开始陷入某种“分裂”。看着那些熟悉的文件夹结构、.md 格式的说明书、以及被封装在 /sc ripts 里的 Python 脚本，觉得特别熟悉，特别放心，但是又觉得哪儿不对：
“当全世界都在兴奋于 AI 的涌现和不确定性时，试图用文件系统、版本控制这些源于90 年代的旧工具和思维去约束它，会不会是‘刻舟求剑’呢？”
我在Youtue和国内外的一些文章，也看了另外一派观点：
“在LLM驱动的生成式 AI 的浪潮下，Prompt 是新的编程语言，自然语言将吞噬一切。按照这个逻辑，任何试图把 AI 塞回“代码逻辑”笼子的行为，似乎都是一种反动，是对原生 Agent 创新能力的抑制”。
夸张点说，我有时候也问自己，我们是不是“抱着旧时代的残党”呢？
站在我们这一代从“正统”走过来的从业人员角度，一场“正统”和“非正统”的“新旧冲突”，最近总是在我自己的脑子里发生。
做一个可能不那么准确，但足够直观的类比：
AI 是“量子力学”的：基于概率，有幻觉，有创造。魅力在于“模糊的正确”与“意外的涌现”。
传统的软件是“牛顿力学”的：以我所在的财经IT领域为例，追求的是“绝对的精准”。代码没写的逻辑，系统绝不能自作主张。
我在我们领域内，也经常和很多同事说，我们要越来越适应：开发范式迁徙，从“确定性编程”走向“概率性推理引导”。
代入我当前所在的财经IT领域的视角，如果我们完全拥抱“新范式”，我们会得到一个极具创意但不可控的 Agent——它可能写出一篇完美的深度分析报告，但也可能因为一次幻觉而调用错误的某个财经系统的接口。所以在当下的技术条件和成熟度下，我们还无法为了追求 AI 的“原生创新和涌现”，就丢掉财经系统的“原生准确和安全”。
当然我也足够相信业界会不断的卷大模型，卷各种为Agent服务的工程技术，最终实现完美的双向奔赴，此消彼长，最终实现Agentic AI，最终有一定概率“非正统”替代“正统”，继而成为新的“正统”。
但是，在这之前，我们需要一个中间层。我们需要一个既能理解“量子态”的模糊意图和推理，又能执行“牛顿态”的精确指令的架构。
Anthropic 推出的 Agent Skills，从这个视角看，正是这样一个维系平衡的“双模架构”（Bimodal Architecture）。
最近我在写一个“洞察哨兵 Skills”，用于追踪全球 AI 厂商的技术动态。在这个过程中，我发现 Skills 这个机制“相对完美”的支撑了这种“新旧冲突”中的协作。
“涌现、推理”交给 SKILL.md： 我们用自然语言编写指令，其实是否允许模糊，允许推理，是我们可控的。比如：“分析一下这家 AI 厂商最近的动作是否有安全风险。” —— 这是 AI 的主场。
“高确定性执行” 交给 /sc ripts： 我们完全可以继续用 Python 写死规则，零容忍，零误差。比如：“抓取 JSON 数据，计算 Diff。” —— 这是代码精确控制的主场。
大家可以感受一下我让 AI 辅助生成的两个 Skills 片段（备注这些片段不是我原始新建的，我让AI帮我生成部分，我自己按我的洞察诉求和风格改了部分，另外如下只是片段，copy到茶思这个编辑器里面，知道有没有格式丢失，不一定复制就能用）
全部版块
我的主页
收藏
---
name: ai_sentinel
desc ription: >
专门用于追踪和洞察全球 AI 厂商（如 Anthropic, OpenAI, Google）的技术动态、API 变更及产品发布。
当用户询问“XX 厂商最近更新了什么”或需要对比不同厂商的某项技术规格时触发。
该技能具备差异化分析能力，能够从杂乱的非结构化信息中萃取商业洞察。
---
# 角色指令
你现在的身份是“AI 竞争情报专家”。你的目标是绕过公关辞令，直接分析技术本质。
# 工作流 (Workflow)
1. 情报抓取：调用 `sc ripts/fetch_latest_feeds.py` 获取目标厂商最近 72 小时的官推、博客及文档变更。
2. 知识对齐：读取 `resources/tech_dictionary.json`，确保将不同厂商的术语（如 GPTs vs Skills）进行准确对齐。
3. 深度 Diff：如果涉及文档更新，必须调用 `sc ripts/semantic_diff.py`，找出指令语义层面的微小调整。
4. 洞察生成：基于 `resources/insight_fr amework.md` 模板，从“开发者影响”、“商业策略”、“算力消耗”三个维度输出报告。
# 执行守则 (Guidelines)
- 拒绝幻觉：如果脚本返回的数据中没有确切日期，严禁主观推测发布时间。
- 颗粒度控制：只关注具有“生产力变革”意义的更新，忽略UI颜色的细微调整。
- 引用溯源：每一条洞察必须附带来源脚本抓取的原始片段摘要。
# 示例交互
- 用户： "Anthropic 的新 Skills 和 OpenAI 的 GPTs 有什么本质区别？"
- 逻辑： 触发 Skill -> 调用资源库对比 -> 输出基于“确定性架构”vs“黑盒架构”的对比报告。
---
name: ai_finance_intelligence_sentinel
desc ription: >
专门用于追踪 AI 厂商技术变动并评估其对财经 IT 架构影响的专家技能。
当识别到模型 Header 变更、新函数调用能力发布时自动触发。
---
# 决策指令 (The Intelligence)
1. 嗅探与对齐：调用 `sc ripts/diff_engine.py`，对比厂商官网前后 24 小时的文档差异。
2. 财经视角转换：读取 `resources/risk_matrix.json`。不要只看技术更新，要分析它是否降低了我们在“实时结算场景”下的推理延迟。
3. 拒绝模糊：如果更新属于非关键 UI 调整（如颜色、字体），直接过滤，不消耗后续推理资源。
# 资源依赖
- /sc ripts/semantic_fetch.py : 绕过公关词汇，直接提取 JSON 定义。
- /resources/compliance_template.md : 生成符合金融监管合规要求的技术变更报告。
说实话，在我自己选的这个洞察场景，我一直是这样一种状态：“你先发挥”->“好，留下来”->“不行，这个地方，你还是按我的来”->“诶，你这个比我想的好，用你的”->“不行，你还是没有太懂我，算了，不试了，你就执行这个Python脚本吧”
就是一种神奇的“协作”，整个过程，大模型不断理解我，懂我（新），瞎推的我用Python脚本约束（旧），就这样“新旧”不断的碰撞，最后好像还总能拼出一个能用的洞察小工具。
在这个过程中，虽然偶尔会有“到底是我在陪大模型玩，还是它在陪我玩”的错觉。当然，也许我这个洞察场景，没有啥代表性，但是在当下的AI技术成熟度的情况下，这就是我们一直在寻找的“中间态正统”吧？—— 让 AI 负责“想一些”，让代码负责“做一些”。
本来都写到结语了，把结语写完了，忍不住又多想了一些。我觉得 Agent Skills 只是这场“新旧范式冲突与平衡”的开端。这种“双模”思维对 Agent 的其他核心要素同样具有一点启示作用：
“记忆”的双模化：目前的 Agent 记忆，要么是全丢给大模型的“感性记忆”（基于向量检索，容易模糊）；要么是死板的数据库或缓存。未来，真正的企业级 Agent 需要“双模记忆”——既拥有能随聊随忘、产生联想的“非结构化直觉”，也必须挂载一套经过一致性校验、不可篡改的“硬核账本记忆”。在涉及资金和权属的场景下，Agent 的“脑子”可以模糊，但它的“账本”必须绝对精准。
“评估”的双模化：评价一个 Agent 的好坏，不能只靠“AI 互评”这种概率套概率的游戏。在关键路径上，必须引入基于逻辑代码的“硬性校验”（如数据勾稽关系、合规性断言），而将表达的丰富性交给 AI 评分。
当然，随着 Skills 模式的规模化引入，作为架构师，我预感到几个避不开的工程挑战，目前还给不出完美答案，先抛砖引玉：
警惕“技能通胀”：我们要克制那种为每个微小功能都建一个 Skill 的冲动。技能堆积越多，Agent 在决策时的“选择困难症”就越严重。架构逻辑上，建议按“业务边界”而非单纯的“功能点”进行 Skill 的逻辑划分。
“Skills 图谱”会不会出现？：在复杂的现实领域，Skill A 的输出可能是 Skill B 的前置依赖。这种“拔出萝卜带出泥”的依赖关系，可能会让 Agent 的动态加载变得极度沉重。我们是否需要引入一层“Skills 关系图谱”来辅助治理？但这是否又陷入了“多加一层对象来解决旧问题”的循环？
存量 IT 应用的“Skill 化”？：不论是我司还是数字化程度高的企业，存量应用才是业务主干。Agent 肯定要大量复用这些能力，但这些沉重的遗留系统（Legacy Systems）是否都能被顺畅地“Skill 化”？是重新封装 API，还是让 Agent 直接学习现有的作业逻辑？这可能是 Agent 真正进入核心业务流程的“最后十公里”。
Agent Skills只是一个引子，未来还会出现很多新的工程技术，和大模型一起双向奔赴，螺旋上升，螺旋卷，最终奔向Artificial Intelligence的终极形态。
“新旧并存的双模架构”，或许正是大模型进入企业核心业务、实现从“极客玩具”到“核心生产力”跨越的一个路径，但是这个路径是比较规矩的一个路径，保不齐后面还会有很多“野路子”让人眼前一亮，走出一条不同的路。比如当下非常火的OpenClaw（这儿说它是野路子的代表，并没有任何的鄙视，只是觉得是真“野”：））
扫码加好友，拉您进群
