尧图网站建设 
最近在折腾 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远不止是一段提示词。它是一个完整的、可执行的“技能包”至少包含以下几个部分描述Description用自然语言定义这个技能是什么、解决什么问题。提示词Prompt核心的指令模板可能包含变量占位符。输入模式Input Schema明确定义这个技能需要哪些输入参数它们的类型、格式和约束。这相当于函数的参数签名。输出期望Output Expectations描述技能执行后应该产生什么样的结果。依赖Dependencies这个技能运行所依赖的其他 Skills 或 Tools。例如一个“代码审查” Skill其输入模式可能是一个file_path和language提示词中会包含针对该语言的审查要点它可能依赖一个“读取文件”的 Tool。这个 Skill 被定义后就可以像调用一个函数一样在任何需要的地方被智能体使用。它的价值在于将一次成功的、包含多轮对话的复杂交互固化成一个标准的、带有接口定义的模块。下次你需要代码审查时无需重新描述规则直接调用这个 Skill传入文件路径即可。2.2 Tools标准化外部能力接口Tools在 Hexis 中代表智能体可以与外部世界交互的能力。这和我们常说的 AI 智能体的“工具调用”功能一致但 Hexis 对其进行了标准化封装工具定义包括工具名称、描述、以及严格的输入/输出模式通常用 JSON Schema 定义。执行器Executor真正执行工具调用的代码逻辑。这可以是本地函数、HTTP API 调用、Shell 命令等。配置管理Tools 所需的配置如 API 密钥、服务器地址被集中管理并与工具定义分离提高了安全性。Hexis 的关键在于它将 Tools 的定义与实现也纳入了版本控制。你可以有一个“查询数据库”的 Tool 定义而其具体的连接字符串配置则可以通过环境变量或加密配置文件来管理不会硬编码在版本库中。2.3 Context动态的、结构化的知识库这是 Hexis 中最有想象力的部分。Context不是指 AI 模型的那个“上下文窗口”而是指为特定任务或领域准备的、结构化的背景信息集合。一个 Context 可能包含文档DocumentsMarkdown、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在里面创建两个文件schema.md: 描述 CSV 文件的列名、数据类型、含义。# 应用日志格式说明 文件app_*.csv 列 - timestamp: ISO 8601 时间戳记录事件发生时间。 - level: 字符串日志级别。可选值INFO, WARN, ERROR。 - service: 字符串产生日志的微服务名称。 - message: 字符串日志内容。 - user_id: 整数关联的用户ID可能为空。sample.csv: 一个小的样例文件包含几条真实数据。现在我们通过 Hexis 命令将这个目录注册为一个可用的 Contexthexis context create log-format --path ./contexts/log-format --description “应用日志的数据格式和样例”这个操作会在.hexis配置中记录这个 Context并将其内容索引化便于后续检索。3.3 第二步创建 Tool赋予能力智能体需要能读取文件。我们来创建一个简单的“读取文件” Tool。在tools/目录下创建read_file.yamlHexis 可能支持 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(encodingutf-8) return {success: True, content: content} except Exception as e: return {success: False, content: f读取文件失败: {str(e)}}使用 Hexis 注册这个 Toolhexis tool register ./tools/read_file.yaml3.4 第三步创建 Skill组合能力与知识现在我们可以创建核心的 Skill 了。在skills/目录下创建analyze_log.yamlname: 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 的按需注入。注册这个 Skillhexis skill create ./skills/analyze_log.yaml3.5 第四步使用与迭代现在你可以通过 Hexis CLI 或将其集成到你的 AI 应用中来调用这个 Skillhexis skill run analyze_log --inputs {log_file_pattern: logs/app_*.csv, time_range: last 3 days}Hexis 会解析 Skill 定义。获取log-formatContext 的相关内容。准备一个包含了read_fileTool 定义、Context 知识和具体 Prompt 的“任务包”。将这个包发送给你配置的 AI 模型如 GPT-4, Claude 等。模型在执行过程中当需要读取文件时会调用read_fileToolHexis 会路由这个调用到我们实现的 Python 函数并将结果返回给模型。最终模型生成分析报告。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 工作流变革从“对话”到“开发”技能即代码Skills as CodeSkill 的定义文件YAML/JSON就是源代码。这意味着你可以进行代码审查Code Review、编写测试例如用固定的输入验证 Skill 输出是否符合预期、甚至建立 CI/CD 流水线自动部署更新后的 Skill 到生产环境。上下文即数据Context as DataContext 目录就是你的知识库。你可以用 ETL 流程自动更新里面的文档和样例Hexis 会自动重新索引。这确保了智能体永远基于最新的知识工作。协作标准化团队共享一个 Hexis 项目仓库就如同共享一个代码库。新人 onboarding 时git pull之后就能获得团队积累的所有 Skills 和 Contexts极大降低了学习成本。环境隔离与复用你可以为不同的项目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 感兴趣我建议按以下路径尝试个人探索期在本地创建一个 Hexis 项目尝试将你每周重复超过 3 次的手动 AI 任务如周报生成、代码审查、文档总结封装成 1-2 个 Skills。重点感受“一次定义多次使用”和“修改 Prompt 有迹可循”的好处。小团队共享期将你的 Hexis 项目推送到 Git 仓库如 GitHub Private Repo。邀请一两个同事克隆并教会他们如何运行你创建的 Skill。收集他们对 Skill 接口输入参数和输出质量的反馈共同迭代。项目标准化期在一个具体的项目如产品文档问答助手中正式使用 Hexis。建立项目的 Context产品文档、API 手册设计一套相关的 Skills查询功能、生成示例代码、对比版本差异。将 Hexis 项目的加载和 Skill 调用写入该项目的开发或运维脚本中。平台化考量期当团队积累了大量有价值的 Skills 和 Contexts 后可以考虑搭建一个简单的内部门户让非技术成员也能通过 Web 界面搜索和调用这些 Skills而无需接触 Git 和命令行。此时Hexis 的后端管理能力就成为核心基础设施。5. 总结Hexis 的本质是“AI 能力的工程化”回过头看Hexis 的出现并非偶然。当 AI 从聊天玩具走向生产力工具时工程化是必经之路。工程化的核心诉求就是可重复、可管理、可协作、可演进。Hexis 通过借用软件工程中最成熟的思想——版本控制Git为 AI 的 Skills、Tools、Context 提供了一个优雅的抽象和管理层。它可能不是唯一解也不是最终解但它清晰地指出了一个方向未来我们与 AI 的协作将越来越像在编写和调用一个由自然语言和代码混合定义的、可组合的“智能程序”。它提醒我们与其在每次对话中徒劳地重复描述复杂需求不如花点时间将那些被验证有效的交互模式沉淀为版本化的、可共享的资产。这不仅仅是提升效率更是在构建属于你自己或你团队的“智能能力图谱”。所以下次当你又在重复向 AI 描述一个复杂任务时不妨停下来想一想这个任务是否值得被封装成一个 Hexis Skill 用Git管理AI技能：Hexis如何实现AI能力的工程化与版本控制
最近在折腾 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远不止是一段提示词。它是一个完整的、可执行的“技能包”至少包含以下几个部分描述Description用自然语言定义这个技能是什么、解决什么问题。提示词Prompt核心的指令模板可能包含变量占位符。输入模式Input Schema明确定义这个技能需要哪些输入参数它们的类型、格式和约束。这相当于函数的参数签名。输出期望Output Expectations描述技能执行后应该产生什么样的结果。依赖Dependencies这个技能运行所依赖的其他 Skills 或 Tools。例如一个“代码审查” Skill其输入模式可能是一个file_path和language提示词中会包含针对该语言的审查要点它可能依赖一个“读取文件”的 Tool。这个 Skill 被定义后就可以像调用一个函数一样在任何需要的地方被智能体使用。它的价值在于将一次成功的、包含多轮对话的复杂交互固化成一个标准的、带有接口定义的模块。下次你需要代码审查时无需重新描述规则直接调用这个 Skill传入文件路径即可。2.2 Tools标准化外部能力接口Tools在 Hexis 中代表智能体可以与外部世界交互的能力。这和我们常说的 AI 智能体的“工具调用”功能一致但 Hexis 对其进行了标准化封装工具定义包括工具名称、描述、以及严格的输入/输出模式通常用 JSON Schema 定义。执行器Executor真正执行工具调用的代码逻辑。这可以是本地函数、HTTP API 调用、Shell 命令等。配置管理Tools 所需的配置如 API 密钥、服务器地址被集中管理并与工具定义分离提高了安全性。Hexis 的关键在于它将 Tools 的定义与实现也纳入了版本控制。你可以有一个“查询数据库”的 Tool 定义而其具体的连接字符串配置则可以通过环境变量或加密配置文件来管理不会硬编码在版本库中。2.3 Context动态的、结构化的知识库这是 Hexis 中最有想象力的部分。Context不是指 AI 模型的那个“上下文窗口”而是指为特定任务或领域准备的、结构化的背景信息集合。一个 Context 可能包含文档DocumentsMarkdown、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在里面创建两个文件schema.md: 描述 CSV 文件的列名、数据类型、含义。# 应用日志格式说明 文件app_*.csv 列 - timestamp: ISO 8601 时间戳记录事件发生时间。 - level: 字符串日志级别。可选值INFO, WARN, ERROR。 - service: 字符串产生日志的微服务名称。 - message: 字符串日志内容。 - user_id: 整数关联的用户ID可能为空。sample.csv: 一个小的样例文件包含几条真实数据。现在我们通过 Hexis 命令将这个目录注册为一个可用的 Contexthexis context create log-format --path ./contexts/log-format --description “应用日志的数据格式和样例”这个操作会在.hexis配置中记录这个 Context并将其内容索引化便于后续检索。3.3 第二步创建 Tool赋予能力智能体需要能读取文件。我们来创建一个简单的“读取文件” Tool。在tools/目录下创建read_file.yamlHexis 可能支持 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(encodingutf-8) return {success: True, content: content} except Exception as e: return {success: False, content: f读取文件失败: {str(e)}}使用 Hexis 注册这个 Toolhexis tool register ./tools/read_file.yaml3.4 第三步创建 Skill组合能力与知识现在我们可以创建核心的 Skill 了。在skills/目录下创建analyze_log.yamlname: 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 的按需注入。注册这个 Skillhexis skill create ./skills/analyze_log.yaml3.5 第四步使用与迭代现在你可以通过 Hexis CLI 或将其集成到你的 AI 应用中来调用这个 Skillhexis skill run analyze_log --inputs {log_file_pattern: logs/app_*.csv, time_range: last 3 days}Hexis 会解析 Skill 定义。获取log-formatContext 的相关内容。准备一个包含了read_fileTool 定义、Context 知识和具体 Prompt 的“任务包”。将这个包发送给你配置的 AI 模型如 GPT-4, Claude 等。模型在执行过程中当需要读取文件时会调用read_fileToolHexis 会路由这个调用到我们实现的 Python 函数并将结果返回给模型。最终模型生成分析报告。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 工作流变革从“对话”到“开发”技能即代码Skills as CodeSkill 的定义文件YAML/JSON就是源代码。这意味着你可以进行代码审查Code Review、编写测试例如用固定的输入验证 Skill 输出是否符合预期、甚至建立 CI/CD 流水线自动部署更新后的 Skill 到生产环境。上下文即数据Context as DataContext 目录就是你的知识库。你可以用 ETL 流程自动更新里面的文档和样例Hexis 会自动重新索引。这确保了智能体永远基于最新的知识工作。协作标准化团队共享一个 Hexis 项目仓库就如同共享一个代码库。新人 onboarding 时git pull之后就能获得团队积累的所有 Skills 和 Contexts极大降低了学习成本。环境隔离与复用你可以为不同的项目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 感兴趣我建议按以下路径尝试个人探索期在本地创建一个 Hexis 项目尝试将你每周重复超过 3 次的手动 AI 任务如周报生成、代码审查、文档总结封装成 1-2 个 Skills。重点感受“一次定义多次使用”和“修改 Prompt 有迹可循”的好处。小团队共享期将你的 Hexis 项目推送到 Git 仓库如 GitHub Private Repo。邀请一两个同事克隆并教会他们如何运行你创建的 Skill。收集他们对 Skill 接口输入参数和输出质量的反馈共同迭代。项目标准化期在一个具体的项目如产品文档问答助手中正式使用 Hexis。建立项目的 Context产品文档、API 手册设计一套相关的 Skills查询功能、生成示例代码、对比版本差异。将 Hexis 项目的加载和 Skill 调用写入该项目的开发或运维脚本中。平台化考量期当团队积累了大量有价值的 Skills 和 Contexts 后可以考虑搭建一个简单的内部门户让非技术成员也能通过 Web 界面搜索和调用这些 Skills而无需接触 Git 和命令行。此时Hexis 的后端管理能力就成为核心基础设施。5. 总结Hexis 的本质是“AI 能力的工程化”回过头看Hexis 的出现并非偶然。当 AI 从聊天玩具走向生产力工具时工程化是必经之路。工程化的核心诉求就是可重复、可管理、可协作、可演进。Hexis 通过借用软件工程中最成熟的思想——版本控制Git为 AI 的 Skills、Tools、Context 提供了一个优雅的抽象和管理层。它可能不是唯一解也不是最终解但它清晰地指出了一个方向未来我们与 AI 的协作将越来越像在编写和调用一个由自然语言和代码混合定义的、可组合的“智能程序”。它提醒我们与其在每次对话中徒劳地重复描述复杂需求不如花点时间将那些被验证有效的交互模式沉淀为版本化的、可共享的资产。这不仅仅是提升效率更是在构建属于你自己或你团队的“智能能力图谱”。所以下次当你又在重复向 AI 描述一个复杂任务时不妨停下来想一想这个任务是否值得被封装成一个 Hexis Skill