Logic 与 Skill：AI Agent 能力封装的两条路线

同一个问题，两种解法——从 Palantir Logic 和 Claude Code Skill 看 AI 能力复用的分岔口

AI AgentSkillPalantirLogicClaude Code能力封装企业AI

最近跟不少人聊 Skill，发现一个问题出现的频率越来越高：

"Skill 生态这么好，是不是用 Skill 就够了？"

问这个问题的人，通常刚体验过 Claude Code 的 Skill 系统——几行 Markdown 就能封装一个可复用的能力，社区里几百个现成的 Skill 可以直接装，Git 一推全团队共享。再看看隔壁 LangChain 的 Tools、CrewAI 的 Tools、Semantic Kernel 的 Plugin（它最早也叫 Skill）——整个行业似乎都在朝着同一个方向收敛。

但如果你同时关注企业 AI 这条线，会注意到 Palantir 在用一个不同的词描述一个看起来很像的东西：Logic。

Palantir 的 CTO Shyam Sankar 反复强调一句话："价值不在模型，在模型和企业系统之间的 Logic 层。"听起来很像 Skill 的理念——LLM 裸跑不够用，你得封装可复用的能力。

那它们到底是同一个东西的不同叫法，还是根本不同的两条路？这篇文章尝试把这个问题聊清楚。

一、先看共同点：它们在解决同一个问题

不管叫 Skill 还是 Logic，出发点是一样的：LLM 有通用智能，但没有专业流程。

一个大语言模型知道什么是 PDF，知道 Python 可以处理 PDF，甚至能写出处理 PDF 的代码。但它不知道你们公司的 PDF 报告格式、不知道你处理 PDF 时惯用哪个库、不知道你每次都要先检查文件头再做解析。

每次都从头解释这些，是对上下文窗口的浪费，也是对人类耐心的消耗。

所以，无论是 Skill 还是 Logic，核心目标一致：把"怎么做"这件事封装起来，让 AI 能反复使用。

它们共享几个底层特征：

封装。 把一组操作步骤和领域知识打包成一个独立单元。Claude Code 的 Skill 用一个 SKILL.md 文件封装所有指令和资源；Palantir 的 Logic 用 TypeScript Functions 封装操作本体对象的业务规则。形式不同，本质相同——都是把散落的知识和流程收拢到一个可管理的边界内。

复用。 写一次，用多次。一个写好的 Skill 可以在所有项目中使用，一个定义好的 Logic Function 可以被多个应用、多个 AIP Agent 调用。这是最直接的效率提升。

可组合。 小能力可以拼成大能力。Skill 可以在执行过程中调用其他工具、触发其他 Skill；Logic 中的 Function 可以调用其他 Function，Action 可以串联多个 Function。组合性让能力可以像积木一样搭建。

声明式描述。 两者都需要"告诉 AI 什么时候该用我"。Skill 靠 description 字段做语义匹配；Logic 靠 Ontology 的类型系统和 AIP 的工具注册机制。没有这一层声明，AI 就不知道自己手里有什么牌。

如果只看到这里，很容易得出结论：这就是一回事，换了个名字。

但别急。

二、分歧从"给谁用"开始

Skill 的世界观是以个人开发者为中心的。

看一下 Claude Code Skill 的设计选择就能理解这种取向：

一个 Skill 的全部配置是一个 Markdown 文件。不需要数据库、不需要平台、不需要部署流程。你在项目的 .claude/skills/ 目录下放一个文件夹，写一个 SKILL.md，它就生效了。用 Git 推到远程仓库，团队成员拉下来就能用。

触发机制是语义驱动的——Claude 读了你的 Skill 描述，判断当前任务匹配，就自动激活。你也可以用 /skill-name 手动调用。整个过程没有审批、没有权限链、没有部署环节。

这种设计极度追求低摩擦。一个开发者从"想封装一个能力"到"这个能力可用"，中间的距离可能只有五分钟和一个文本编辑器。

Logic 的世界观是以企业运营为中心的。

Palantir 的 Logic 建立在一个完全不同的假设之上：使用它的不是一个人，而是一个组织；操作的不是本地文件，而是企业数据资产；产出的不是代码或文档，而是业务决策。

Logic 运行在 Ontology 之上——企业先把业务实体（客户、订单、设备、供应商）建模为本体对象，定义对象之间的关系和属性，然后 Logic 在这个语义层上进行计算。一个 Logic Function 看到的不是文件路径和目录结构，而是"这个供应商的交货准时率"和"该工厂上月的停机次数"。

每一次 Logic 执行都有完整的审计日志——谁触发的、输入了什么、产出了什么、经过了哪些审批节点。在国防、医疗、金融这些强监管行业，这不是锦上添花，而是基本门槛。

这种设计追求的不是低摩擦，而是可控性。

三、五个维度的具体差异

把两者放在一起看，差异在几个关键维度上非常清晰：

触发机制。 Skill 靠自然语言描述做语义匹配——Claude 读 description，判断"这个任务看起来跟这个 Skill 有关"，然后自动加载。这是一种模糊的、概率性的匹配。Logic 的触发要精确得多：一个 Ontology 事件（某个对象的属性变更）、一个用户操作（点击"审批"按钮）、一个 AIP Agent 的工具调用——都是明确的、可追溯的触发路径。

数据上下文。 Skill 看到的是本地文件系统——你的代码仓库、你的 Markdown 文件、你终端里的命令输出。Logic 看到的是企业本体——经过清洗、建模、权限管控的结构化业务数据。这是最根本的区别之一。Skill 操作的是"你的电脑里有什么"，Logic 操作的是"这个企业知道什么"。

治理模型。 Skill 的治理接近于零——它信任开发者。虽然已经有了 allowed-tools 权限控制和 disable-model-invocation 防止自动触发，但本质上还是一个"开发者自律"模型。Logic 是全链路治理：RBAC 角色权限、人工审批门控、执行审计、数据血缘。你可以精确追溯"上周三下午，谁用了哪个 Logic，处理了哪些数据，做了什么决策"。

确定性。 Skill 的执行本质上是非确定性的——同一个 Skill 在相似场景下可能产生不同的输出，因为核心驱动力是 LLM 的概率推理。Logic 提供了混合确定性：传统的 if-then 规则和 TypeScript 函数是完全确定的，LLM 环节是概率性的，但被确定性的上下游步骤约束。对于企业来说，"这个决策流程在相同条件下产出相同结果"往往是合规要求。

生态模型。 Skill 的生态是开放的——通过 Git 分享、通过插件市场安装、社区贡献驱动。任何人都可以写一个 Skill，打包成 .skill 文件发布。Logic 的生态是封闭的——它存在于 Palantir 平台内部，由企业团队创建和维护，不存在"社区 Logic 市场"。这是 Skill 被广泛讨论的核心原因之一：它是可以触碰的，而 Logic 藏在企业的围墙花园里。

四、不是替代，是分层

看完上面的对比，你可能已经有了直觉：这两个东西不在同一个层面竞争。

一个类比可能有帮助。

Skill 像是个人的工作习惯。 你总是用同样的方式处理 PDF、总是用同样的步骤做 code review、总是用同样的模板写技术文档。你把这些习惯写下来，变成 Skill，以后就不用每次重复了。它的受益者是你自己（以及跟你工作方式相似的人）。

Logic 像是企业的 SOP。 新员工入职时有一套流程，客户投诉处理有一套流程，药品上市审批有一套流程。这些流程不是某个人的个人偏好，而是组织层面的决策规则，需要被执行、被监督、被审计。

你不会用个人习惯去管理一个 500 人工厂的生产流程——因为你需要权限控制、审批节点、异常处理机制、可追溯性。你也不会用一套企业 SOP 来管理你今天怎么写代码——因为那个重量级是不必要的。

所以，面对"用 Skill 是不是就够了"这个问题，判断标准其实很清晰。问自己三个问题：

决策后果是否可逆？ 如果出了错可以轻松回退（比如代码改错了、文档写歪了），Skill 就够用。如果决策影响资金流动、合规审查、客户关系，你需要 Logic 级别的治理。

是否需要跨人、跨部门协作？ 如果这个能力只有你和你的团队在用，Skill 的轻量分享模型完全足够。如果它涉及多个部门、多种角色、需要审批链，Logic 的组织化设计才是对的工具。

数据是否需要统一语义？ 如果你操作的是本地文件和项目代码，Skill 天然适配。如果你需要在企业级数据资产上进行计算——客户数据、交易数据、设备数据——你需要一个 Ontology 作为语义基座，Logic 就是为此而生的。

五、一个可能的未来：Skill 长出治理，Logic 长出生态

有意思的是，两条路线并非各走各的，而是在向对方的领地渗透。

Skill 在长出治理能力。

Claude Code 的 Skill 系统已经出现了明显的治理萌芽：allowed-tools 让你可以控制一个 Skill 能使用哪些工具；disable-model-invocation 防止 AI 自动触发高风险操作；企业托管设置允许组织级别统一下发 Skill 规范。更进一步，Skill 支持权限规则，管理员可以精确控制哪些 Skill 可以被使用、哪些需要被禁止。

这些功能单独看都不起眼，但组合在一起，方向很明确：Skill 正在从"个人效率工具"向"可治理的组织能力单元"演进。

Logic 在长出易用性。

Palantir 在 AIPCon 上展示了越来越低门槛的 Logic 构建体验——可视化工作流编辑器、自然语言描述转 Logic、低代码 Rules 编辑器（让非工程师也能定义业务规则）。AIP Logic 本身就是对传统 Logic 的一次重大易用性升级：用户可以用自然语言描述意图，由 LLM 编排 Logic Functions 的执行。

这也是一个清晰的方向：Logic 正在从"只有平台工程师才能碰的东西"向"业务人员也能构建的能力"演进。

两条路线的交汇点或许是：有治理能力的 Skill，或有开放生态的 Logic。

但短期内，分工格局是稳定的。个人和小团队的生产力场景，Skill 的轻量和生态优势不可替代。企业级决策流和合规场景，Logic 的治理和本体架构是必需品。硬要用一个替代另一个，就像用瑞士军刀切牛排，或者用厨房全套刀具削苹果——技术上可行，但尴尬。

写在最后

回到开头那个问题：用 Skill 是不是就够了？

答案是：取决于你在哪一层。

如果你是一个开发者，想让 AI 更高效地帮你干活——写代码、处理文件、自动化工作流——Skill 不仅够用，而且是目前最好的选择。它的低门槛、高灵活性、开放生态，正是个人生产力场景需要的。

如果你面对的是企业级场景——多人协作、强监管、高风险决策、复杂数据资产——你需要的不只是"能力封装"，还有"治理框架"。这时候 Logic（或类似的企业级能力编排方案）才是正确的工具。

技术选型从来不是信仰问题。不要问"哪个更好"，要问"我的场景需要什么级别的能力封装"。

这个判断框架，可能比任何具体技术的生命周期都更长。

如果你对 AI Agent、企业 AI 架构和开发者工具感兴趣，欢迎关注「啤酒的夏天」。我们聊技术，也聊技术背后的思考方式。