最近在折腾 AI 应用时，我遇到了一个很典型的问题：好不容易调教好一个能处理特定任务的智能体（Agent），换台机器或者想分享给同事时，却发现一切又得重来。那些精心设计的提示词（Prompt）、配置好的工具（Tools）、以及为特定任务准备的上下文（Context），都散落在聊天记录、本地配置文件和脑子里，难以复用和版本化管理。

这让我开始思考，我们为 AI 准备“技能包”的方式，是不是还停留在手工作坊时代？直到我遇到了Hexis这个项目。它的核心理念非常直接：用 Git 的方式来管理 AI 的 Skills（技能）、Tools（工具）和 Context（上下文）。初看这个描述，你可能会觉得“哦，又一个用 Git 做版本控制的工具”。但深入使用后，我发现它真正解决的，远不止是“版本控制”那么简单。它试图回答一个更本质的问题：如何将一次性的、临时的 AI 交互，沉淀为可复用、可协作、可迭代的工程化资产？

今天，我们就来深入聊聊 Hexis，看看它如何用 Git 的思维，重塑我们与 AI 协作的工作流。

1. 从“一次性对话”到“可复用资产”：Hexis 要解决的根本问题

在深入 Hexis 的具体功能前，我们先得理解它要啃的硬骨头是什么。当前我们使用 AI 智能体，尤其是那些能调用工具、拥有长上下文能力的智能体时，普遍存在几个痛点：

痛点一：技能与经验的“黑箱化”与“碎片化”。你通过多次对话，教会了一个智能体如何用特定格式处理数据、如何调用某个 API、甚至如何根据你的代码风格进行审查。这些“技能”和“经验”都存在于某次对话的上下文里。一旦开启新对话，或者想在其他项目中使用，这些积累就消失了。你不得不重新描述需求、上传文件、调整参数，整个过程低效且不可靠。

痛点二：工具链的配置与管理混乱。一个功能强大的智能体往往需要接入多种工具：代码解释器、网络搜索、自定义 API、数据库查询等。这些工具的配置（如 API 密钥、端点地址、调用参数）通常散落在环境变量、配置文件或提示词中。没有统一的管理方式，迁移和共享变得异常困难，且存在安全风险。

痛点三：上下文（Context）的构建成本高昂。对于复杂任务，我们需要为智能体准备高质量的上下文：可能是项目文档、代码库结构、API 说明、历史决策记录等。每次手动整理和喂给 AI 都是一项耗时的工作。更重要的是，这些上下文本身也在迭代更新，如何同步这些变化，确保智能体总是基于最新、最相关的信息工作，是一个挑战。

痛点四：缺乏协作与知识沉淀的路径。在团队中，A 成员摸索出的高效提示词和工具调用流程，很难系统地传递给 B 成员。每个人都在重复造轮子，团队无法形成关于“如何更好地使用 AI”的共享知识库。

Hexis 的答案很清晰：像管理代码一样管理 AI 的能力。它将 Skills、Tools、Context 这些抽象概念，具体化为可以用 Git 进行版本控制、分支、合并、回滚的实体文件。这不仅仅是加了一个“.git”文件夹那么简单，而是一种工作范式的转变——将 AI 从临时的、对话式的助手，转变为可编程、可集成、可运维的系统组件。

2. Hexis 核心概念拆解：Skills, Tools, Context 到底是什么？

要理解 Hexis，必须厘清它定义的三个核心实体。它们不是凭空创造的新词，而是对现有 AI 使用模式的高度抽象和封装。

2.1 Skills：封装可复用的任务流程

在 Hexis 的语境里，一个Skill远不止是一段提示词。它是一个完整的、可执行的“技能包”，至少包含以下几个部分：

1. 描述（Description）：用自然语言定义这个技能是什么、解决什么问题。
2. 提示词（Prompt）：核心的指令模板，可能包含变量占位符。
3. 输入模式（Input Schema）：明确定义这个技能需要哪些输入参数，它们的类型、格式和约束。这相当于函数的参数签名。
4. 输出期望（Output Expectations）：描述技能执行后应该产生什么样的结果。
5. 依赖（Dependencies）：这个技能运行所依赖的其他 Skills 或 Tools。

例如，一个“代码审查” Skill，其输入模式可能是一个file_path和language，提示词中会包含针对该语言的审查要点，它可能依赖一个“读取文件”的 Tool。这个 Skill 被定义后，就可以像调用一个函数一样，在任何需要的地方被智能体使用。

它的价值在于：将一次成功的、包含多轮对话的复杂交互，固化成一个标准的、带有接口定义的模块。下次你需要代码审查时，无需重新描述规则，直接调用这个 Skill，传入文件路径即可。

2.2 Tools：标准化外部能力接口

Tools在 Hexis 中代表智能体可以与外部世界交互的能力。这和我们常说的 AI 智能体的“工具调用”功能一致，但 Hexis 对其进行了标准化封装：

1. 工具定义：包括工具名称、描述、以及严格的输入/输出模式（通常用 JSON Schema 定义）。
2. 执行器（Executor）：真正执行工具调用的代码逻辑。这可以是本地函数、HTTP API 调用、Shell 命令等。
3. 配置管理：Tools 所需的配置（如 API 密钥、服务器地址）被集中管理，并与工具定义分离，提高了安全性。

Hexis 的关键在于，它将 Tools 的定义与实现也纳入了版本控制。你可以有一个“查询数据库”的 Tool 定义，而其具体的连接字符串配置，则可以通过环境变量或加密配置文件来管理，不会硬编码在版本库中。

2.3 Context：动态的、结构化的知识库

这是 Hexis 中最有想象力的部分。Context不是指 AI 模型的那个“上下文窗口”，而是指为特定任务或领域准备的、结构化的背景信息集合。

一个 Context 可能包含：

• 文档（Documents）：Markdown、PDF、文本文件等。
• 代码片段（Code Snippets）：关键的函数、类或配置文件。
• 数据样本（Data Samples）：示例输入输出。
• 元数据（Metadata）：描述这些信息如何被索引、检索和关联。

Hexis 允许你为不同的项目或任务创建不同的 Context。当智能体需要处理相关任务时，Hexis 可以自动地、智能地从对应的 Context 中检索最相关的信息，并注入到对话中。这解决了“每次都要重新上传文件”的麻烦，也使得智能体能够基于一个持续更新的知识库进行工作。

三者关系：你可以把Context看作智能体的“长期记忆”或“知识库”，Tools是它的“手和脚”，而Skills则是它调用手脚、运用知识来完成特定任务的“方法”或“程序”。Hexis 用 Git 把这三者的定义、配置和内容都管理了起来。

3. 实战：如何用 Hexis 构建一个“数据分析助手”技能

概念讲得再多，不如动手试一次。我们假设要构建一个 Skill，让 AI 助手能分析我们项目目录下的 CSV 日志文件，并生成总结报告。看看 Hexis 如何让这个过程变得工程化。

3.1 初始化与项目结构

首先，你需要安装 Hexis（通常是一个 Python 包或 CLI 工具）。初始化一个 Hexis 项目：

hexis init my-data-analyzer cd my-data-analyzer

你会看到一个类似这样的结构被创建：

my-data-analyzer/ ├── .hexis/ │ ├── config.yaml # 项目级配置 │ └── ... # 内部管理文件 ├── skills/ # 存放所有 Skill 定义 │ └── README.md ├── tools/ # 存放所有 Tool 定义 │ └── README.md ├── contexts/ # 存放所有 Context 数据 │ └── README.md └── .git/ # 标准的 Git 仓库

这已经清晰地表明了 Hexis 的领域划分。所有内容都在 Git 管理之下。

3.2 第一步：创建 Context（准备知识）

我们的任务是分析 CSV 日志。首先，我们需要让助手了解日志的格式。在contexts/下创建一个log-format目录：

mkdir -p contexts/log-format

在里面创建两个文件：

1. schema.md: 描述 CSV 文件的列名、数据类型、含义。

   # 应用日志格式说明 文件：`app_*.csv` 列： - `timestamp`: ISO 8601 时间戳，记录事件发生时间。 - `level`: 字符串，日志级别。可选值：INFO, WARN, ERROR。 - `service`: 字符串，产生日志的微服务名称。 - `message`: 字符串，日志内容。 - `user_id`: 整数，关联的用户ID（可能为空）。

2. sample.csv: 一个小的样例文件，包含几条真实数据。

现在，我们通过 Hexis 命令将这个目录注册为一个可用的 Context：

hexis context create log-format --path ./contexts/log-format --description “应用日志的数据格式和样例”

这个操作会在.hexis配置中记录这个 Context，并将其内容索引化，便于后续检索。

3.3 第二步：创建 Tool（赋予能力）

智能体需要能读取文件。我们来创建一个简单的“读取文件” Tool。在tools/目录下创建read_file.yaml（Hexis 可能支持 YAML 或 JSON 定义）：

name: read_file description: 读取指定路径的文本文件内容。 input_schema: type: object properties: file_path: type: string description: 文件的相对或绝对路径。 required: [file_path] output_schema: type: object properties: content: type: string description: 文件的内容。 success: type: boolean executor: type: python handler: tools.handlers.read_file # 指向实际的 Python 函数

同时，我们需要实现tools/handlers.py里的read_file函数：

import os from pathlib import Path def read_file(file_path: str) -> dict: """实际的工具执行器""" try: # Hexis 可能会提供项目根目录等上下文信息 full_path = Path(file_path) if not full_path.is_absolute(): # 假设有一个基础目录，比如当前项目根目录 base_dir = Path(os.getenv("HEXIS_PROJECT_ROOT", ".")) full_path = base_dir / full_path if not full_path.exists(): return {"success": False, "content": f"文件不存在: {file_path}"} content = full_path.read_text(encoding='utf-8') return {"success": True, "content": content} except Exception as e: return {"success": False, "content": f"读取文件失败: {str(e)}"}

使用 Hexis 注册这个 Tool：

hexis tool register ./tools/read_file.yaml

3.4 第三步：创建 Skill（组合能力与知识）

现在，我们可以创建核心的 Skill 了。在skills/目录下创建analyze_log.yaml：

name: analyze_log description: 分析指定 CSV 日志文件，总结错误趋势、服务状态和用户影响。 inputs: - name: log_file_pattern type: string description: 日志文件的路径或通配符模式（如 `logs/app_*.csv`）。 - name: time_range type: string description: 可选。时间范围，如 “last 7 days”。默认为分析所有数据。 prompt: | 你是一个数据分析助手。你的任务是分析给定的应用日志文件，并生成一份简洁的报告。 ## 知识参考 以下是日志文件的格式说明，请严格依据此格式理解数据： {{ context “log-format” | relevant_to “schema” }} ## 任务步骤 1. 使用 `read_file` 工具读取 `{{ log_file_pattern }}` 匹配的文件。 2. 解析 CSV 数据，理解 `timestamp`, `level`, `service`, `message`, `user_id` 字段。 3. 根据 `{{ time_range | default: “all” }}` 过滤数据。 4. 分析并报告： - 各级别（INFO, WARN, ERROR）日志的数量和比例。 - 哪个服务（`service` 字段）产生的 ERROR 最多。 - 是否有随时间变化的错误趋势（例如，某个时间段错误激增）。 - 受影响的用户（`user_id` 非空的 ERROR 日志）涉及多少独立用户。 5. 将分析结果用清晰的 Markdown 格式输出，包含关键数据和简要结论。 dependencies: tools: - read_file contexts: - log-format

注意 Prompt 中的{{ context “log-format” | relevant_to “schema” }}，这是一个模板语法，指示 Hexis 在运行时，从log-format这个 Context 中检索与“schema”最相关的部分，并动态插入到提示词中。这实现了 Context 的按需注入。

注册这个 Skill：

hexis skill create ./skills/analyze_log.yaml

3.5 第四步：使用与迭代

现在，你可以通过 Hexis CLI 或将其集成到你的 AI 应用中来调用这个 Skill：

hexis skill run analyze_log --inputs '{"log_file_pattern": "logs/app_*.csv", "time_range": "last 3 days"}'

Hexis 会：

1. 解析 Skill 定义。
2. 获取log-formatContext 的相关内容。
3. 准备一个包含了read_fileTool 定义、Context 知识和具体 Prompt 的“任务包”。
4. 将这个包发送给你配置的 AI 模型（如 GPT-4, Claude 等）。
5. 模型在执行过程中，当需要读取文件时，会调用read_fileTool，Hexis 会路由这个调用到我们实现的 Python 函数，并将结果返回给模型。
6. 最终，模型生成分析报告。

Git 的力量在此刻显现：如果你发现分析报告忽略了某个重要维度，你可以修改analyze_log.yaml中的 Prompt。如果你发现日志格式新增了一列，你可以更新contexts/log-format/schema.md。所有这些更改，都通过git commit留下了清晰的记录。你可以创建分支（git branch feature/new-metric）来试验新的分析指标，成熟后再合并到主分支。你的同事可以通过git clone和hexis project load一键获得这个完整的“数据分析助手”能力。

4. 超越工具：Hexis 带来的工作流变革与潜在挑战

通过上面的例子，你应该能感受到 Hexis 不仅仅是另一个工具集。它引入了一种新的、基于版本控制的 AI 能力开发范式。但这套范式要真正落地，还需要我们思考几个关键问题。

4.1 工作流变革：从“对话”到“开发”

1. 技能即代码（Skills as Code）：Skill 的定义文件（YAML/JSON）就是源代码。这意味着你可以进行代码审查（Code Review）、编写测试（例如，用固定的输入验证 Skill 输出是否符合预期）、甚至建立 CI/CD 流水线，自动部署更新后的 Skill 到生产环境。
2. 上下文即数据（Context as Data）：Context 目录就是你的知识库。你可以用 ETL 流程自动更新里面的文档和样例，Hexis 会自动重新索引。这确保了智能体永远基于最新的知识工作。
3. 协作标准化：团队共享一个 Hexis 项目仓库，就如同共享一个代码库。新人 onboarding 时，git pull之后就能获得团队积累的所有 Skills 和 Contexts，极大降低了学习成本。
4. 环境隔离与复用：你可以为不同的项目（Project A, Project B）创建不同的 Hexis 项目，它们之间的 Skills 和 Tools 可以通过 Git Submodule 或包管理的方式复用，避免了全局配置的污染和冲突。

4.2 当前面临的挑战与注意事项

尽管理念先进，但在实际采用 Hexis 或类似方案时，你需要清醒地认识到一些挑战：

挑战一：抽象与复杂度的平衡。Hexis 引入了 YAML 定义、目录结构、CLI 命令等新概念。对于只想快速问 AI 一个问题的新手来说，学习成本陡增。它更适合那些已经频繁使用 AI、并且痛点明确（如需要重复执行复杂任务）的开发者或团队。建议：从小处着手，先封装一个你最常重复的任务为 Skill，体验其价值，再逐步推广。

挑战二：Prompt 工程的版本管理依然微妙。虽然 Prompt 文本被保存在了文件里，但 AI 模型的非确定性意味着，同样的 Prompt 在不同时间、不同模型版本下，输出可能波动。Git 可以管理 Prompt 的变更，但无法完全锁定输出结果。建议：为关键的 Skill 建立输出快照测试，用固定的输入集定期运行，监控输出质量的变化。

挑战三：Tool 执行的安全性与可靠性。Hexis 将 Tool 的执行权交给了用户定义的函数（如我们的read_file）。这带来了巨大的灵活性，也带来了安全风险。一个设计不当的 Tool 可能被 AI 滥用，导致文件删除、数据泄露或系统调用风险。建议：

• 严格遵循最小权限原则，Tool 的执行环境应被沙盒化。
• 对 Tool 的输入进行严格的模式验证和净化。
• 建立 Tool 的审计日志，记录所有调用和结果。

挑战四：Context 检索的质量依赖。Hexis 的{{ context ... | relevant_to ... }}语法背后是检索增强生成（RAG）技术。其效果严重依赖于 Context 内容的结构化程度、索引方式和检索策略。如果检索不到或检索不准，会直接导致 AI 的“知识”出错。建议：精心设计 Context 文档的结构，使用清晰的标题和关键词。对于关键知识，考虑使用更结构化的数据格式（如 JSON Schema）而非纯文本。

挑战五：与现有 AI 应用架构的集成。Hexis 可以作为一个独立的技能管理中间件。你需要考虑如何将它接入你现有的 AI 应用框架（如 LangChain、LlamaIndex 或自定义的后端）。是直接使用其 CLI，还是将其作为 Python 库调用？这需要一些集成工作。

4.3 我的使用建议：分阶段采纳

如果你对 Hexis 感兴趣，我建议按以下路径尝试：

1. 个人探索期：在本地创建一个 Hexis 项目，尝试将你每周重复超过 3 次的手动 AI 任务（如周报生成、代码审查、文档总结）封装成 1-2 个 Skills。重点感受“一次定义，多次使用”和“修改 Prompt 有迹可循”的好处。
2. 小团队共享期：将你的 Hexis 项目推送到 Git 仓库（如 GitHub Private Repo）。邀请一两个同事克隆，并教会他们如何运行你创建的 Skill。收集他们对 Skill 接口（输入参数）和输出质量的反馈，共同迭代。
3. 项目标准化期：在一个具体的项目（如产品文档问答助手）中，正式使用 Hexis。建立项目的 Context（产品文档、API 手册），设计一套相关的 Skills（查询功能、生成示例代码、对比版本差异）。将 Hexis 项目的加载和 Skill 调用，写入该项目的开发或运维脚本中。
4. 平台化考量期：当团队积累了大量有价值的 Skills 和 Contexts 后，可以考虑搭建一个简单的内部门户，让非技术成员也能通过 Web 界面搜索和调用这些 Skills，而无需接触 Git 和命令行。此时，Hexis 的后端管理能力就成为核心基础设施。

5. 总结：Hexis 的本质是“AI 能力的工程化”

回过头看，Hexis 的出现并非偶然。当 AI 从聊天玩具走向生产力工具时，工程化是必经之路。工程化的核心诉求就是：可重复、可管理、可协作、可演进。

Hexis 通过借用软件工程中最成熟的思想——版本控制（Git），为 AI 的 Skills、Tools、Context 提供了一个优雅的抽象和管理层。它可能不是唯一解，也不是最终解，但它清晰地指出了一个方向：未来我们与 AI 的协作，将越来越像在编写和调用一个由自然语言和代码混合定义的、可组合的“智能程序”。

它提醒我们，与其在每次对话中徒劳地重复描述复杂需求，不如花点时间，将那些被验证有效的交互模式，沉淀为版本化的、可共享的资产。这不仅仅是提升效率，更是在构建属于你自己或你团队的“智能能力图谱”。

所以，下次当你又在重复向 AI 描述一个复杂任务时，不妨停下来想一想：这个任务，是否值得被封装成一个 Hexis Skill？