1. 从“魔法符文”到“类型化缰绳”SIGIL 项目初探最近在 Agent 和 AI 应用开发领域一个名为 SIGIL 的项目开始引起一些讨论。它的全称是 “Compiling Agent Skills into Typed Harnesses”直译过来是“将智能体技能编译成类型化的缰绳”。这个标题听起来有点抽象结合“SIGIL”这个词本身在奇幻文化中常指“魔法符文”或“印记”以及“Harnesses”缰绳/约束装置这个工程术语它精准地指向了当前 AI 应用开发中的一个核心痛点如何将那些灵活但不可靠的 AI 能力Skills转化为稳定、可预测、可组合的工程化组件Typed Harnesses。简单来说你可以把现在的 AI 大模型尤其是 Agent 模式下的调用想象成一匹拥有无穷力量但难以预测的野马。它能完成复杂的任务Skill比如根据自然语言指令去操作数据库、调用 API、生成代码但它的行为边界模糊输出格式飘忽不定错误处理机制几乎为零。而 SIGIL 的目标就是为这匹“野马”锻造一套精密的“缰绳”和“马鞍”——一套类型系统Typed和运行时框架Harness使得开发者能够像调用一个普通函数一样安全、可靠地调用 AI 能力并且能将多个这样的能力像乐高积木一样组合起来构建出更复杂的应用。这背后反映的是 AI 工程化从“演示阶段”迈向“生产阶段”的必然需求。当 AI 能力不再仅仅是聊天机器人里的炫技而要深度集成到企业的业务流程、开发者的工具链中时可靠性、可维护性和可组合性就成了必须跨越的门槛。SIGIL 提出的“编译”思路正是试图用编程语言和编译器的经典思想来解决 AI 应用开发中的这一新兴挑战。接下来我们将深入拆解 SIGIL 可能涉及的核心概念、技术原理以及它试图构建的应用场景。2. 核心概念拆解Skill、Harness 与 “编译” 究竟指什么要理解 SIGIL必须厘清其标题中的三个关键词Skill技能、Harness缰绳/约束装置和 Compiling编译。它们共同构成了该项目的方法论基石。2.1 Agent Skills超越简单提示词的“可执行能力”在当前的 AI 应用语境下一个 “Skill” 远不止是一个精心设计的提示词Prompt。它是一个封装了特定意图、能力、上下文和交互协议的完整单元。例如一个数据查询 Skill可能包括1理解用户自然语言查询意图的提示词2将意图转换为特定数据库如 SQL或 API如 GraphQL查询的逻辑3处理查询结果并格式化为用户可读答案的后处理逻辑4处理查询失败、权限不足等异常情况的机制。一个代码生成 Skill可能包括1接收功能描述和约束条件如编程语言、框架2结合现有代码库的上下文3生成符合特定风格和测试要求的代码片段4甚至包含一个运行单元测试来验证生成代码的环节。Skill 的核心特点是声明性和目标导向。开发者声明“我想要一个能做什么的能力”而不必完全关心大模型内部是如何一步步推理实现的。这与近期热门的MCPModel Context Protocol有相似之处都旨在标准化 AI 与工具/数据的交互方式。但区别可能在于MCP 更侧重于定义一套通用的“模型-服务器”通信协议让模型能动态发现和调用工具而 SIGIL 中的 Skill 可能更偏向于一个经过预先设计、封装和验证的、带有强类型接口的“能力包”其可靠性和可预测性通过“编译”过程得到增强。2.2 Typed Harnesses为不确定性套上确定性的“笼头”“Harness”在软件测试中常指“测试夹具”或“约束框架”其作用是将被测对象置于一个可控的环境中施加输入并观察输出。在 SIGIL 的语境下Typed Harness类型化缰绳就是为不确定的 AI Skill 套上的一个确定性外壳。这个“外壳”主要通过类型系统Type System来实现输入类型约束明确定义一个 Skill 需要什么样的输入。不仅是数据类型字符串、数字、列表更是语义类型UserIdSQLQueryStringFilePath。这能在调用前就过滤掉大量无效或危险的请求。输出类型保证强制 Skill 的输出必须符合声明的类型。例如一个声称返回JSONObject的 Skill其输出必须能被解析为合法的 JSON并且结构符合预期。这通过后处理、验证甚至模型输出格式的强制引导来实现。副作用与错误类型化明确 Skill 会执行哪些操作如“写入数据库”、“发送邮件”以及可能抛出哪些类型的错误如NetworkErrorPermissionDeniedErrorInvalidInputError。这让错误处理变得可编程。运行时监控与兜底Harness 在 Skill 运行时提供监控、超时控制、重试逻辑以及预定义的失败回退方案Fallback。为什么是“Typed”因为类型是编程语言中用于定义契约、在编译期捕获错误、并指导工具链如IDE自动补全的核心机制。将 AI Skill “类型化”意味着将 AI 的能力纳入传统的、可靠的软件开发范式之中。开发者可以像使用函数库一样通过类型签名来理解和使用 AI SkillIDE 可以提供智能提示静态分析工具可以检查 Skill 组合的兼容性。2.3 Compiling从抽象描述到可执行容器的转化过程“编译”是 SIGIL 最精妙的一环。它不是一个比喻而是指一个类似编译器将高级语言翻译成机器码的自动化过程。这个过程可能包括以下几个阶段Skill 声明开发者用一种高级的领域特定语言DSL或注解声明一个 Skill 的意图、输入输出类型、约束条件、所需资源等。这相当于编写“高级语言”代码。# 假设的 SIGIL DSL 示例 skill: GenerateAPITestCode description: “根据 API 接口定义生成 Python pytest 测试代码” input: - name: api_spec type: OpenAPISpec - name: framework type: string enum: [pytest, unittest] output: type: PythonSourceCode constraints: max_tokens: 2000 timeout: 30s分析与验证SIGIL 的“编译器”会分析这个声明检查类型一致性解析依赖例如这个 Skill 内部可能需要调用另一个“解析 OpenAPI 规范”的 Skill。代码生成与合成编译器根据声明自动生成或组装出实现该 Skill 所需的“胶水代码”。这可能包括提示词模板的优化与固化将声明中的约束条件如输出必须是合法的 Python 代码编译成强化在提示词中的系统指令。验证逻辑的插入在模型调用前后自动插入输入验证和输出解析/验证的代码例如用 Pydantic 模型验证输出 JSON。运行时逻辑的包装生成处理异步、流式响应、重试、降级的包装器代码。生成接口定义为生成的 Skill 生成对应编程语言如 Python、TypeScript的类型定义文件.d.ts或pyi文件方便集成。打包为 Harness最终产物是一个“类型化缰绳”——一个具有清晰、稳定 API 的软件包它内部封装了所有与 AI 模型交互的复杂性对外则暴露出一个看起来完全传统、可依赖的编程接口。通过这个“编译”过程原本黑盒的、提示词驱动的 AI 交互被提升为了白盒的、契约驱动的软件组件。3. SIGIL 可能的技术实现路径与架构猜想虽然 SIGIL 项目的具体实现细节未公开但我们可以基于软件工程和 AI 工程化的现有实践对其技术架构进行合理的推测。一个完整的 SIGIL 系统可能包含以下核心模块3.1 核心编译器前端Skill 定义语言与解析器首先需要一套用于定义 Skill 的语法。它可能是一种独立的 DSL如上述 YAML 示例也可能是嵌入在现有编程语言中的注解Decorator或宏Macro。Python 注解示例猜想from sigil import skill, Typed skill Typed(inputOpenAPISpec, outputPythonSourceCode) def generate_test_code(api_spec: OpenAPISpec, framework: str pytest) - PythonSourceCode: 根据 OpenAPI 规范生成测试代码。 约束输出必须是可运行的 pytest 测试用例。 # 函数体可能为空或包含一些引导性逻辑 # 实际的 AI 调用和提示词合成由编译器在后端处理 ...编译器前端会解析这些注解提取出类型信息、描述和约束生成一个中间表示IR为后续的优化和代码生成做准备。3.2 类型系统与约束求解器这是 SIGIL 的“大脑”。它需要管理一套丰富的类型包括基本类型、AI 特有的类型如NaturalLanguageQuery以及用户自定义的类型。更关键的是它要能处理约束。约束传播如果一个 Skill A 的输出类型是T1而 Skill B 的输入类型要求是T2且T1是T2的子类型那么 A 和 B 可以直接组合。编译器需要能进行这种类型推理。约束求解某些约束可能更复杂比如“输出列表的长度必须等于输入列表的长度”。编译器可能需要调用一个约束求解器或在生成的代码中插入运行时断言。3.3 提示词工程与模板编译模块这是将声明式约束“编译”进模型交互的关键。该模块负责结构化提示词生成根据 Skill 的类型签名和描述自动组装系统指令、少样本示例Few-shot Examples和用户查询的模板。例如如果输出类型是JSONObject系统指令中会强烈要求模型以 JSON 格式响应。约束注入将“输出必须是合法 Python 代码”这样的约束转化为模型能更好理解的指令比如“请确保你生成的代码可以直接被 Python 3.8 解释器执行不要包含任何解释性文字”。上下文管理自动管理对话历史、工具调用结果等上下文并将其格式化为符合模型要求的提示词部分。3.4 运行时代码生成与 Harness 组装编译器后端接收中间表示并针对目标运行时环境如 Python asyncio, Node.js生成具体的代码。生成客户端代码生成一个类或函数其参数和返回值类型与 Skill 声明一致。内部封装了对 AI 模型 API如 OpenAI, Anthropic的调用、错误处理、重试逻辑等。集成验证库自动集成像 PydanticPython或 ZodTypeScript这样的验证库为输入输出生成对应的验证模型。生成依赖描述生成requirements.txt或package.json声明生成的 Harness 所依赖的 AI SDK 和验证库。3.5 注册中心与依赖管理类似于软件包管理器如 PyPI, npmSIGIL 可能需要一个中心化的 Skill 注册中心。开发者可以发布编译好的、类型化的 HarnessSkill 包其他开发者可以像安装普通库一样安装它们并通过类型系统安全地组合使用。注册中心会存储每个 Skill 的类型签名、版本、性能指标和兼容性信息。4. 实战推演如何用 SIGIL 思维构建一个代码审查 Agent让我们通过一个具体的例子——构建一个“代码审查 Agent”——来感受 SIGIL 方法带来的改变。假设我们要创建一个 Skill它能接收一段 Python 代码和一个审查重点如“安全检查”、“性能优化”返回结构化的审查意见。4.1 传统提示词工程 vs. SIGIL 方式传统方式写一个复杂的提示词“你是一个资深 Python 开发者请审查以下代码重点关注 {focus}。请以 JSON 格式返回包含issue问题描述、line行号、severity严重程度high/medium/low、suggestion修改建议等字段。”在代码中调用大模型 API传入提示词和代码。在收到响应后手动解析 JSON处理解析失败的情况。将结果展示给用户。痛点JSON 格式可能被破坏模型可能忽略某些审查重点没有错误类型所有错误都是通用的这个“能力”难以和其他操作如自动创建 GitLab Issue组合。SIGIL 方式声明 Skillfrom sigil import skill, Typed from dataclasses import dataclass from enum import Enum class Severity(Enum): HIGH high MEDIUM medium LOW low dataclass class CodeIssue: description: str line_number: int severity: Severity suggestion: str dataclass class CodeReviewResult: issues: List[CodeIssue] summary: str skill Typed(input(str, str), outputCodeReviewResult) # 输入代码字符串和焦点字符串 def review_python_code(code: str, focus: str) - CodeReviewResult: 审查 Python 代码返回结构化的问题列表和总结。编译与使用SIGIL 编译器读取上述声明理解到需要生成一个返回CodeReviewResult对象的 Skill。它自动生成一个强类型的提示词模板并强制模型输出能被CodeReviewResultPydantic 模型解析的 JSON。它生成一个review_python_code函数开发者可以直接调用result: CodeReviewResult await review_python_code(my_code, security) for issue in result.issues: if issue.severity Severity.HIGH: print(f[高危] 第{issue.line_number}行: {issue.description}) print(f建议: {issue.suggestion})优势调用方无需关心提示词细节返回值是类型安全的对象IDE 能自动补全issue.severity等属性如果模型返回了非法 JSON 或缺少必填字段Harness 会抛出一个清晰的ValidationError而非崩溃这个CodeReviewResult类型可以轻松传递给下一个 Skill例如create_gitlab_issue(result.issues[0])。4.2 组合多个 Skill 构建工作流SIGIL 的真正威力在于组合。假设我们还有另一个从仓库获取代码的 Skillfetch_code_from_pr和一个创建任务的 Skillcreate_jira_ticket。# 这些函数都是经过 SIGIL 编译后的类型化 Harness async def automated_pr_review(pr_url: str): # Skill 1: 获取代码 repo_info, diff_code await fetch_code_from_pr(pr_url) # Skill 2: 审查代码可并行审查不同重点 security_review await review_python_code(diff_code, security) perf_review await review_python_code(diff_code, performance) # 组合结果进行业务逻辑判断 all_critical_issues [i for i in security_review.issues perf_review.issues if i.severity Severity.HIGH] if all_critical_issues: # Skill 3: 创建 Jira 任务 for issue in all_critical_issues: ticket_id await create_jira_ticket( titlef代码审查高危问题: {issue.description[:50]}..., descriptionissue.description \n\n建议 issue.suggestion, componentCode-Quality ) print(f已创建任务: {ticket_id}) else: print(PR 审查通过无高危问题。)在这个工作流中每个步骤都是类型安全、错误处理明确的。编译器甚至可以在编译期就检查create_jira_ticket是否接受CodeIssue类型的输入或者review_python_code的返回值是否能被后续逻辑正确处理提前发现接口不匹配的错误。5. SIGIL 带来的范式转变与潜在挑战SIGIL 所代表的“编译 Agent Skills”思想不仅仅是一个工具更是一种范式的转变。它将 AI 应用开发从“提示词炼金术”转向了“软件工程”。5.1 核心价值可预测性、可维护性与可组合性可预测性类型化的接口使得 AI 组件的行为边界变得清晰。开发者可以基于契约进行开发而不是基于对模型行为的猜测。测试也变得可行——你可以为 Harness 编写单元测试模拟输入并断言输出类型和结构。可维护性当需要更新一个 Skill 时例如更换底层模型、优化提示词只要其类型接口保持不变调用方代码就无需修改。Skill 的实现细节被很好地隐藏在了 Harness 内部。可组合性这是最大的价值。类型系统为自动化的 Skill 编排Orchestration提供了基础。未来可能会出现基于 SIGIL 的“可视化工作流编辑器”通过拖拽类型匹配的 Skill 节点来构建复杂 Agent编译器自动生成所有胶水代码。5.2 面临的挑战与思考然而这条道路也布满挑战类型系统的表达能力限制如何用类型系统精确描述自然语言的语义NaturalLanguageQuery这个类型太宽泛了。是否需要更细粒度的类型如QuestionAboutWeatherCommandToControlSmartDevice这可能导致类型系统变得极其复杂。编译期验证的局限性很多 AI 行为的正确性无法在编译期验证。类型安全不代表功能正确。一个返回类型为CorrectAnswer的 Skill仍然可能给出错误答案。这需要结合运行时监控、评估和持续验证。性能开销“编译”过程本身以及生成的验证代码、包装器都会引入额外的开销。对于低延迟场景需要精细的优化。生态建设像任何编程范式一样SIGIL 的成功依赖于丰富的“类型化 Skill 库”生态。这需要社区和厂商共同推动制定标准提供高质量、维护良好的基础 Skill。5.3 与现有技术栈的融合SIGIL 不会取代现有的 AI 框架如 LangChain、LlamaIndex而是可能构建其上或与其互补。这些框架提供了构建 AI 应用的基础设施如链、记忆、工具调用而 SIGIL 可以为其产出的“能力单元”提供类型化封装和编译优化。同样它与 MCP 的关系也可能是互补的——MCP 负责动态的工具发现和调用而 SIGIL 负责将这些工具调用封装成静态的、类型安全的本地函数。从网络热词“sigil 批量删除第几行”的误读可以看出社区对可靠工具的需求是迫切的。虽然这是一个对“SIGIL”的误解可能源于对某个文本编辑操作的需求但它恰恰反映了开发者渴望有一种“确定性的魔法”——一个能精准执行“删除第 N 行”这种原子操作且绝不会出错的工具。SIGIL 项目正是在尝试将 AI 那宏大却模糊的“魔法”编译成无数个这样可靠、精准的“类型化缰绳”。这条路很长但方向无疑是通往 AI 应用工业化生产的必经之路。对于一线开发者而言即使不等待 SIGIL 这样的完整解决方案其思想——用强接口封装 AI 能力、用契约驱动开发、追求组件的可组合性——也值得在当下的 AI 应用开发实践中立即采纳。 SIGIL：将AI技能编译为类型化组件的工程化实践
1. 从“魔法符文”到“类型化缰绳”SIGIL 项目初探最近在 Agent 和 AI 应用开发领域一个名为 SIGIL 的项目开始引起一些讨论。它的全称是 “Compiling Agent Skills into Typed Harnesses”直译过来是“将智能体技能编译成类型化的缰绳”。这个标题听起来有点抽象结合“SIGIL”这个词本身在奇幻文化中常指“魔法符文”或“印记”以及“Harnesses”缰绳/约束装置这个工程术语它精准地指向了当前 AI 应用开发中的一个核心痛点如何将那些灵活但不可靠的 AI 能力Skills转化为稳定、可预测、可组合的工程化组件Typed Harnesses。简单来说你可以把现在的 AI 大模型尤其是 Agent 模式下的调用想象成一匹拥有无穷力量但难以预测的野马。它能完成复杂的任务Skill比如根据自然语言指令去操作数据库、调用 API、生成代码但它的行为边界模糊输出格式飘忽不定错误处理机制几乎为零。而 SIGIL 的目标就是为这匹“野马”锻造一套精密的“缰绳”和“马鞍”——一套类型系统Typed和运行时框架Harness使得开发者能够像调用一个普通函数一样安全、可靠地调用 AI 能力并且能将多个这样的能力像乐高积木一样组合起来构建出更复杂的应用。这背后反映的是 AI 工程化从“演示阶段”迈向“生产阶段”的必然需求。当 AI 能力不再仅仅是聊天机器人里的炫技而要深度集成到企业的业务流程、开发者的工具链中时可靠性、可维护性和可组合性就成了必须跨越的门槛。SIGIL 提出的“编译”思路正是试图用编程语言和编译器的经典思想来解决 AI 应用开发中的这一新兴挑战。接下来我们将深入拆解 SIGIL 可能涉及的核心概念、技术原理以及它试图构建的应用场景。2. 核心概念拆解Skill、Harness 与 “编译” 究竟指什么要理解 SIGIL必须厘清其标题中的三个关键词Skill技能、Harness缰绳/约束装置和 Compiling编译。它们共同构成了该项目的方法论基石。2.1 Agent Skills超越简单提示词的“可执行能力”在当前的 AI 应用语境下一个 “Skill” 远不止是一个精心设计的提示词Prompt。它是一个封装了特定意图、能力、上下文和交互协议的完整单元。例如一个数据查询 Skill可能包括1理解用户自然语言查询意图的提示词2将意图转换为特定数据库如 SQL或 API如 GraphQL查询的逻辑3处理查询结果并格式化为用户可读答案的后处理逻辑4处理查询失败、权限不足等异常情况的机制。一个代码生成 Skill可能包括1接收功能描述和约束条件如编程语言、框架2结合现有代码库的上下文3生成符合特定风格和测试要求的代码片段4甚至包含一个运行单元测试来验证生成代码的环节。Skill 的核心特点是声明性和目标导向。开发者声明“我想要一个能做什么的能力”而不必完全关心大模型内部是如何一步步推理实现的。这与近期热门的MCPModel Context Protocol有相似之处都旨在标准化 AI 与工具/数据的交互方式。但区别可能在于MCP 更侧重于定义一套通用的“模型-服务器”通信协议让模型能动态发现和调用工具而 SIGIL 中的 Skill 可能更偏向于一个经过预先设计、封装和验证的、带有强类型接口的“能力包”其可靠性和可预测性通过“编译”过程得到增强。2.2 Typed Harnesses为不确定性套上确定性的“笼头”“Harness”在软件测试中常指“测试夹具”或“约束框架”其作用是将被测对象置于一个可控的环境中施加输入并观察输出。在 SIGIL 的语境下Typed Harness类型化缰绳就是为不确定的 AI Skill 套上的一个确定性外壳。这个“外壳”主要通过类型系统Type System来实现输入类型约束明确定义一个 Skill 需要什么样的输入。不仅是数据类型字符串、数字、列表更是语义类型UserIdSQLQueryStringFilePath。这能在调用前就过滤掉大量无效或危险的请求。输出类型保证强制 Skill 的输出必须符合声明的类型。例如一个声称返回JSONObject的 Skill其输出必须能被解析为合法的 JSON并且结构符合预期。这通过后处理、验证甚至模型输出格式的强制引导来实现。副作用与错误类型化明确 Skill 会执行哪些操作如“写入数据库”、“发送邮件”以及可能抛出哪些类型的错误如NetworkErrorPermissionDeniedErrorInvalidInputError。这让错误处理变得可编程。运行时监控与兜底Harness 在 Skill 运行时提供监控、超时控制、重试逻辑以及预定义的失败回退方案Fallback。为什么是“Typed”因为类型是编程语言中用于定义契约、在编译期捕获错误、并指导工具链如IDE自动补全的核心机制。将 AI Skill “类型化”意味着将 AI 的能力纳入传统的、可靠的软件开发范式之中。开发者可以像使用函数库一样通过类型签名来理解和使用 AI SkillIDE 可以提供智能提示静态分析工具可以检查 Skill 组合的兼容性。2.3 Compiling从抽象描述到可执行容器的转化过程“编译”是 SIGIL 最精妙的一环。它不是一个比喻而是指一个类似编译器将高级语言翻译成机器码的自动化过程。这个过程可能包括以下几个阶段Skill 声明开发者用一种高级的领域特定语言DSL或注解声明一个 Skill 的意图、输入输出类型、约束条件、所需资源等。这相当于编写“高级语言”代码。# 假设的 SIGIL DSL 示例 skill: GenerateAPITestCode description: “根据 API 接口定义生成 Python pytest 测试代码” input: - name: api_spec type: OpenAPISpec - name: framework type: string enum: [pytest, unittest] output: type: PythonSourceCode constraints: max_tokens: 2000 timeout: 30s分析与验证SIGIL 的“编译器”会分析这个声明检查类型一致性解析依赖例如这个 Skill 内部可能需要调用另一个“解析 OpenAPI 规范”的 Skill。代码生成与合成编译器根据声明自动生成或组装出实现该 Skill 所需的“胶水代码”。这可能包括提示词模板的优化与固化将声明中的约束条件如输出必须是合法的 Python 代码编译成强化在提示词中的系统指令。验证逻辑的插入在模型调用前后自动插入输入验证和输出解析/验证的代码例如用 Pydantic 模型验证输出 JSON。运行时逻辑的包装生成处理异步、流式响应、重试、降级的包装器代码。生成接口定义为生成的 Skill 生成对应编程语言如 Python、TypeScript的类型定义文件.d.ts或pyi文件方便集成。打包为 Harness最终产物是一个“类型化缰绳”——一个具有清晰、稳定 API 的软件包它内部封装了所有与 AI 模型交互的复杂性对外则暴露出一个看起来完全传统、可依赖的编程接口。通过这个“编译”过程原本黑盒的、提示词驱动的 AI 交互被提升为了白盒的、契约驱动的软件组件。3. SIGIL 可能的技术实现路径与架构猜想虽然 SIGIL 项目的具体实现细节未公开但我们可以基于软件工程和 AI 工程化的现有实践对其技术架构进行合理的推测。一个完整的 SIGIL 系统可能包含以下核心模块3.1 核心编译器前端Skill 定义语言与解析器首先需要一套用于定义 Skill 的语法。它可能是一种独立的 DSL如上述 YAML 示例也可能是嵌入在现有编程语言中的注解Decorator或宏Macro。Python 注解示例猜想from sigil import skill, Typed skill Typed(inputOpenAPISpec, outputPythonSourceCode) def generate_test_code(api_spec: OpenAPISpec, framework: str pytest) - PythonSourceCode: 根据 OpenAPI 规范生成测试代码。 约束输出必须是可运行的 pytest 测试用例。 # 函数体可能为空或包含一些引导性逻辑 # 实际的 AI 调用和提示词合成由编译器在后端处理 ...编译器前端会解析这些注解提取出类型信息、描述和约束生成一个中间表示IR为后续的优化和代码生成做准备。3.2 类型系统与约束求解器这是 SIGIL 的“大脑”。它需要管理一套丰富的类型包括基本类型、AI 特有的类型如NaturalLanguageQuery以及用户自定义的类型。更关键的是它要能处理约束。约束传播如果一个 Skill A 的输出类型是T1而 Skill B 的输入类型要求是T2且T1是T2的子类型那么 A 和 B 可以直接组合。编译器需要能进行这种类型推理。约束求解某些约束可能更复杂比如“输出列表的长度必须等于输入列表的长度”。编译器可能需要调用一个约束求解器或在生成的代码中插入运行时断言。3.3 提示词工程与模板编译模块这是将声明式约束“编译”进模型交互的关键。该模块负责结构化提示词生成根据 Skill 的类型签名和描述自动组装系统指令、少样本示例Few-shot Examples和用户查询的模板。例如如果输出类型是JSONObject系统指令中会强烈要求模型以 JSON 格式响应。约束注入将“输出必须是合法 Python 代码”这样的约束转化为模型能更好理解的指令比如“请确保你生成的代码可以直接被 Python 3.8 解释器执行不要包含任何解释性文字”。上下文管理自动管理对话历史、工具调用结果等上下文并将其格式化为符合模型要求的提示词部分。3.4 运行时代码生成与 Harness 组装编译器后端接收中间表示并针对目标运行时环境如 Python asyncio, Node.js生成具体的代码。生成客户端代码生成一个类或函数其参数和返回值类型与 Skill 声明一致。内部封装了对 AI 模型 API如 OpenAI, Anthropic的调用、错误处理、重试逻辑等。集成验证库自动集成像 PydanticPython或 ZodTypeScript这样的验证库为输入输出生成对应的验证模型。生成依赖描述生成requirements.txt或package.json声明生成的 Harness 所依赖的 AI SDK 和验证库。3.5 注册中心与依赖管理类似于软件包管理器如 PyPI, npmSIGIL 可能需要一个中心化的 Skill 注册中心。开发者可以发布编译好的、类型化的 HarnessSkill 包其他开发者可以像安装普通库一样安装它们并通过类型系统安全地组合使用。注册中心会存储每个 Skill 的类型签名、版本、性能指标和兼容性信息。4. 实战推演如何用 SIGIL 思维构建一个代码审查 Agent让我们通过一个具体的例子——构建一个“代码审查 Agent”——来感受 SIGIL 方法带来的改变。假设我们要创建一个 Skill它能接收一段 Python 代码和一个审查重点如“安全检查”、“性能优化”返回结构化的审查意见。4.1 传统提示词工程 vs. SIGIL 方式传统方式写一个复杂的提示词“你是一个资深 Python 开发者请审查以下代码重点关注 {focus}。请以 JSON 格式返回包含issue问题描述、line行号、severity严重程度high/medium/low、suggestion修改建议等字段。”在代码中调用大模型 API传入提示词和代码。在收到响应后手动解析 JSON处理解析失败的情况。将结果展示给用户。痛点JSON 格式可能被破坏模型可能忽略某些审查重点没有错误类型所有错误都是通用的这个“能力”难以和其他操作如自动创建 GitLab Issue组合。SIGIL 方式声明 Skillfrom sigil import skill, Typed from dataclasses import dataclass from enum import Enum class Severity(Enum): HIGH high MEDIUM medium LOW low dataclass class CodeIssue: description: str line_number: int severity: Severity suggestion: str dataclass class CodeReviewResult: issues: List[CodeIssue] summary: str skill Typed(input(str, str), outputCodeReviewResult) # 输入代码字符串和焦点字符串 def review_python_code(code: str, focus: str) - CodeReviewResult: 审查 Python 代码返回结构化的问题列表和总结。编译与使用SIGIL 编译器读取上述声明理解到需要生成一个返回CodeReviewResult对象的 Skill。它自动生成一个强类型的提示词模板并强制模型输出能被CodeReviewResultPydantic 模型解析的 JSON。它生成一个review_python_code函数开发者可以直接调用result: CodeReviewResult await review_python_code(my_code, security) for issue in result.issues: if issue.severity Severity.HIGH: print(f[高危] 第{issue.line_number}行: {issue.description}) print(f建议: {issue.suggestion})优势调用方无需关心提示词细节返回值是类型安全的对象IDE 能自动补全issue.severity等属性如果模型返回了非法 JSON 或缺少必填字段Harness 会抛出一个清晰的ValidationError而非崩溃这个CodeReviewResult类型可以轻松传递给下一个 Skill例如create_gitlab_issue(result.issues[0])。4.2 组合多个 Skill 构建工作流SIGIL 的真正威力在于组合。假设我们还有另一个从仓库获取代码的 Skillfetch_code_from_pr和一个创建任务的 Skillcreate_jira_ticket。# 这些函数都是经过 SIGIL 编译后的类型化 Harness async def automated_pr_review(pr_url: str): # Skill 1: 获取代码 repo_info, diff_code await fetch_code_from_pr(pr_url) # Skill 2: 审查代码可并行审查不同重点 security_review await review_python_code(diff_code, security) perf_review await review_python_code(diff_code, performance) # 组合结果进行业务逻辑判断 all_critical_issues [i for i in security_review.issues perf_review.issues if i.severity Severity.HIGH] if all_critical_issues: # Skill 3: 创建 Jira 任务 for issue in all_critical_issues: ticket_id await create_jira_ticket( titlef代码审查高危问题: {issue.description[:50]}..., descriptionissue.description \n\n建议 issue.suggestion, componentCode-Quality ) print(f已创建任务: {ticket_id}) else: print(PR 审查通过无高危问题。)在这个工作流中每个步骤都是类型安全、错误处理明确的。编译器甚至可以在编译期就检查create_jira_ticket是否接受CodeIssue类型的输入或者review_python_code的返回值是否能被后续逻辑正确处理提前发现接口不匹配的错误。5. SIGIL 带来的范式转变与潜在挑战SIGIL 所代表的“编译 Agent Skills”思想不仅仅是一个工具更是一种范式的转变。它将 AI 应用开发从“提示词炼金术”转向了“软件工程”。5.1 核心价值可预测性、可维护性与可组合性可预测性类型化的接口使得 AI 组件的行为边界变得清晰。开发者可以基于契约进行开发而不是基于对模型行为的猜测。测试也变得可行——你可以为 Harness 编写单元测试模拟输入并断言输出类型和结构。可维护性当需要更新一个 Skill 时例如更换底层模型、优化提示词只要其类型接口保持不变调用方代码就无需修改。Skill 的实现细节被很好地隐藏在了 Harness 内部。可组合性这是最大的价值。类型系统为自动化的 Skill 编排Orchestration提供了基础。未来可能会出现基于 SIGIL 的“可视化工作流编辑器”通过拖拽类型匹配的 Skill 节点来构建复杂 Agent编译器自动生成所有胶水代码。5.2 面临的挑战与思考然而这条道路也布满挑战类型系统的表达能力限制如何用类型系统精确描述自然语言的语义NaturalLanguageQuery这个类型太宽泛了。是否需要更细粒度的类型如QuestionAboutWeatherCommandToControlSmartDevice这可能导致类型系统变得极其复杂。编译期验证的局限性很多 AI 行为的正确性无法在编译期验证。类型安全不代表功能正确。一个返回类型为CorrectAnswer的 Skill仍然可能给出错误答案。这需要结合运行时监控、评估和持续验证。性能开销“编译”过程本身以及生成的验证代码、包装器都会引入额外的开销。对于低延迟场景需要精细的优化。生态建设像任何编程范式一样SIGIL 的成功依赖于丰富的“类型化 Skill 库”生态。这需要社区和厂商共同推动制定标准提供高质量、维护良好的基础 Skill。5.3 与现有技术栈的融合SIGIL 不会取代现有的 AI 框架如 LangChain、LlamaIndex而是可能构建其上或与其互补。这些框架提供了构建 AI 应用的基础设施如链、记忆、工具调用而 SIGIL 可以为其产出的“能力单元”提供类型化封装和编译优化。同样它与 MCP 的关系也可能是互补的——MCP 负责动态的工具发现和调用而 SIGIL 负责将这些工具调用封装成静态的、类型安全的本地函数。从网络热词“sigil 批量删除第几行”的误读可以看出社区对可靠工具的需求是迫切的。虽然这是一个对“SIGIL”的误解可能源于对某个文本编辑操作的需求但它恰恰反映了开发者渴望有一种“确定性的魔法”——一个能精准执行“删除第 N 行”这种原子操作且绝不会出错的工具。SIGIL 项目正是在尝试将 AI 那宏大却模糊的“魔法”编译成无数个这样可靠、精准的“类型化缰绳”。这条路很长但方向无疑是通往 AI 应用工业化生产的必经之路。对于一线开发者而言即使不等待 SIGIL 这样的完整解决方案其思想——用强接口封装 AI 能力、用契约驱动开发、追求组件的可组合性——也值得在当下的 AI 应用开发实践中立即采纳。