我们正在把越来越多的专业知识交给 AI Agent。
从简单的提示词，到封装业务经验的 Skill，再到能够独立完成任务的复杂工作流。我们不断教会 Agent 如何工作，也逐渐把自己多年积累的经验沉淀进去。
但最近我一直有个工程上的焦虑：
**我们究竟是在积累自己的能力，还是在不断加深对某个 Agent、模型和运行环境的依赖？**
---
## 问题不在于有没有状态，而在于状态归谁所有
现在的 Agent Harness 和 Runtime 已经相当强大。它们可以管理状态、控制执行、处理中断与恢复，甚至提供完整的审计记录。
这些能力当然有价值，我们也没有必要重新发明一遍。
但如果 Skill 的执行状态、工作流结构和审计证据，全部依赖外部环境来维持呢？
今天用 Claude，明天换成 Codex；今天依赖某个 Harness，明天整个 Runtime 都升级了。
原来的 Skill 还能不能继续使用？执行到哪一步了？哪些检查已经通过？中断之后能否安全恢复？之前产生的证据还能不能被独立检查？
如果这些问题的答案都取决于原来的环境是否还存在，那么我们积累的究竟是自己的 Skill，还是某个工具的附属品？
**这才是我真正焦虑的地方。**
---
## 让 Skill 长出自己的工程脊柱
这也是我最近一直在开发开源项目 Techne Loom 的原因。
我的想法不是取代现有的 Agent、Harness 或 Runtime，而是让 Skill 拥有一套属于自己的、明确的工程结构。
就像人体的脊柱一样，它不需要代替大脑思考，也不需要代替四肢执行，但它应该能够维持整个系统的结构与连续性。
对于一个真正需要长期使用的 Skill，我希望它至少能够保有四类东西：
* **工作流契约：** 明确知道自己应该做什么，而不只是依赖模型对提示词的临场理解。
* **持久化状态：** 知道自己已经做了什么、当前执行到哪里，而不是把聊天记录当作唯一的记忆。
* **结构化恢复边界：** 中断后能够明确知道缺少什么、应该从哪里继续，而不是让模型猜测上一轮发生了什么。
* **可审计的执行证据：** 能够回答实际执行了哪些步骤、产生了什么结果，而不是仅仅相信 Agent 声称自己完成了任务。
目前 Techne Loom 以 .NET 为主要实现，通过 Skill Orchestrator 为这些能力提供明确的工程机制。跨不同 Agent 环境的语义互操作，则是项目持续推进的方向。
这并不意味着 Skill 可以脱离运行环境独立执行，也不意味着所有 Agent 都会产生完全相同的行为。
**我希望改变的是：Skill 的核心结构、执行状态和历史证据，不应该完全由当前运行它的外部环境来定义和拥有。**
---
模型会进化，框架会更迭，今天流行的 Agent 明天可能就被取代。
但我们投入时间积累的专业知识、业务经验和工作方法，不应该跟着某个工具一起消失。
我希望今天写下的 Skill，几年之后依然可以被理解、维护、复用和审计，甚至能够在今天还不存在的环境中继续发挥价值。
**让 Skill 拥有自己的脊柱，而不是永远寄生在某个 Agent 身上。**
这就是我想通过 Techne Loom 探索的方向。
项目已经开源，也很想听听其他工程师的看法：
你们正在积累的 AI Skill，究竟有多少能力真正属于 Skill 自己，又有多少依赖于当前运行它的环境？
GitHub：(http://t.cn/AXO4t7NX)
#AIAgent# #AgentSkills# #AI工程# #开源# #TechneLoom# #Techne-Loom# #How I AI#