# LLM 作为软件函数组件：类型签名、API契约与函数组合模式 > 面向 Software 3.1 架构范式，探讨将 LLM 输出视为软件函数组件的工程化方法，给出类型签名、API 契约设计与函数组合模式。 ## 元数据 - 路径: /posts/2026/02/25/llm-as-function-composition/ - 发布时间: 2026-02-25T00:36:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 站点: https://blog.hotdry.top ## 正文 当我们谈论 Software 3.1 范式时，核心转变在于将大语言模型从「对话界面」提升为「可组合的软件函数」。传统软件开发中，每个模块都有明确的输入输出类型和契约约束；如今，这种工程化思维同样适用于 LLM 驱动的智能系统。本文将从类型签名、API 契约和函数组合三个层面，阐述如何将 LLM 视为软件工程中的可组合组件。 ## 一、核心类型签名：从概率性函数到 Effectful 视图 在类型论视角下，一次 LLM 调用并非传统的纯函数，而是一个概率性函数。设请求为 R、配置为 C、执行前状态为 S，则一次调用的类型签名可以形式化为： ``` LLM : R × C × S → D(O × S') ``` 其中 R 包含提示词、消息历史和工具模式定义；C 包含模型标识、温度参数、最大 token 数等配置；S 表示调用前的系统状态（配额、会话上下文、工具注册表）；O 是输出 payload（文本 token、工具调用或结构化 JSON）；S' 是调用后更新的系统状态；而 D 表示输出上的概率分布——这正是 LLM 与确定性函数的核心区别。 如果将上述签名封装为更符合工程实践的形式，可以采用 Effectful 计算风格： ``` LLM : Request → Config → State → IO(Response × State) ``` 这种视角将 LLM 视为产生副作用的 IO 操作，Response 是从底层分布中采样得到的具体实例。在实际 SDK 设计中，这一层抽象通常被简化为异步函数调用： ```typescript type LLM = (request: LLMRequest) => Promise; ``` 其中 LLMRequest 和 LLMResponse 包含明确的类型字段，后续章节将详细展开。 ## 二、API 契约：TypeScript 类型定义与 Design-by-Contract ### 请求与响应类型 一个实用的 API 契约需要在 JSON Schema 层面固定 Request 和 Response 的结构： ```typescript type ToolSchema = { name: string; description?: string; parameters: JSONSchema; }; type LLMRequest = { messages: Message[]; tools?: ToolSchema[]; config?: { model: string; temperature?: number; max_tokens?: number; }; state?: StateHandle; }; type LLMToolCall = { name: string; arguments: unknown; }; type LLMResponse = { messages: Message[]; tool_calls?: LLMToolCall[]; usage?: { prompt_tokens: number; completion_tokens: number; total_tokens: number; }; newState?: StateHandle; }; ``` 上述类型定义构成了 LLM 函数签名的具体形式：`LLM : LLMRequest → Promise`。 ### 前后置条件 将 Design-by-Contract 思想引入 LLM 调用，可以为每个函数调用附加形式化的前置条件和后置条件。前置条件约束输入的合法性： - `messages` 必须符合允许的角色（system、user、assistant、tool）和格式规范； - 总体 token 长度必须落在模型上下文窗口范围内； - `tools[*].parameters` 必须是合法的 JSON Schema； - `config.temperature` 取值范围为 [0, 2]，其他参数亦需满足类型约束。 后置条件则保证输出的可预期性： - 每个 `tool_call.arguments` 必须通过对应工具的 JSON Schema 验证； - 若 messages 中声明了「format: JSON」约束，assistant 最终消息必须能解析为有效 JSON 并符合指定 schema； - usage 字段间需满足内部一致性（`total = prompt + completion`）。 可以将一个完整的 LLM API 契约形式化为五元组 C = ⟨I, Pre, Post, S, π⟩，其中 I 是接口（Request, Response 对），Pre 是前置条件集合，Post 是后置条件集合，S 是状态空间，π 是由模型决定的隐式输出分布。 ## 三、函数组合模式：LLM Router 与工具函数的顺序组合 在 Agent 架构中，LLM 的角色往往不是直接生成最终答案，而是作为「路由器」或「规划器」，决定在何时调用何种工具。这一模式可以形式化为以下组合： 工具函数本身是确定性函数： ```typescript type Tool = (args: A) => Promise; ``` LLM 则输出工具调用指令： ```typescript type Step = | { kind: "assistant"; message: Message } | { kind: "tool_call"; name: string; args: unknown } | { kind: "final"; result: unknown }; type Agent = (history: Message[], state: S) => Promise<{ step: Step; state: S }>; ``` 组合流程如下：LLM 决策生成 `tool_call(name, args)`；系统校验 `args` 是否符合工具的 JSON Schema；若校验通过，调用对应工具函数 `Tool(name): A → R`；将工具返回结果追加到消息历史，再次调用 LLM 生成下一步。 从类型签名角度看，单个 Agent Step 可以表示为： ``` AgentStep : (H, S) → IO((H', S')) ``` 其中 H 是消息历史，Agent 内部通过组合 LLM 和工具函数完成这一转换。 ## 四、顺序组合规则与契约兼容性 当我们希望从形式化角度推理多个 LLM/工具步骤的组合时，可以将每个步骤视为带契约的 Effectful 函数。设： - C₁ 为「LLM → 工具调用 JSON」的契约； - C₂ 为「tool(args) → 结果」的契约； - C₃ 为「LLM(history + tool result) → 最终 JSON」的契约。 假设 `Post₁` 保证 `args` 符合工具输入 schema，`Pre₂` 恰好要求该 schema；`Post₂` 保证 `result` 符合某个输出 schema，而 `Pre₃` 恰要求该 schema 出现在历史记录中。那么组合后的管道满足一个导出的契约： ``` C = C₁ ; C₂ ; C₃ ``` 其中 `Pre_C = Pre₁`（在该前置条件下所有后续前置条件均被满足），`Post_C = Post₃`（最终保证，例如生成了有效的领域对象）。 这种基于契约兼容性的组合推理方式，使得 LLM + 工具的复杂工作流可以在不依赖临时提示词的情况下被形式化验证。 ## 五、实践参数与监控要点 将理论框架落地到工程实践时，以下参数值得关注： 模型选择与配置方面，建议在生产环境固定 model 版本而非使用「latest」别名；temperature 默认值设为 0.7，针对需要确定性的任务可降至 0.1 以下；max_tokens 需根据输出 schema 预估并留有冗余。契约验证方面，每次 LLM 返回 tool_calls 前必须执行 JSON Schema 校验，校验失败应触发重试或降级而非直接传递给下游；结构化输出场景推荐使用强制 JSON 模式而非依赖提示词。监控指标应覆盖 token 消耗量（用于成本控制）、工具调用成功率、契约校验失败率以及端到端延迟分布。 通过将 LLM 视为带有类型签名和 API 契约的软件函数组件，开发者可以在保持灵活性的同时获得工程化的可预期性与可组合性。这一思路正是 Software 3.1 架构范式的核心价值所在。 --- **参考资料** - Contracts for Large Language Model APIs (Tanzim Hossain Romel) - LAPIS: Lightweight API Specification for Intelligent Systems (arXiv) ## 同分类近期文章 ### [NVIDIA PersonaPlex 双重条件提示工程与全双工架构解析](/posts/2026/04/09/nvidia-personaplex-dual-conditioning-architecture/) - 日期: 2026-04-09T03:04:25+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 NVIDIA PersonaPlex 的双流架构设计、文本提示与语音提示的双重条件机制，以及如何在单模型中实现实时全双工对话与角色切换。 ### [ai-hedge-fund：多代理AI对冲基金的架构设计与信号聚合机制](/posts/2026/04/09/multi-agent-ai-hedge-fund-architecture/) - 日期: 2026-04-09T01:49:57+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析GitHub Trending项目ai-hedge-fund的多代理架构，探讨19个专业角色分工、信号生成管线与风控自动化的工程实现。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation-framework/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [LiteRT-LM C++ 推理运行时：边缘设备的量化、算子融合与内存管理实践](/posts/2026/04/08/litert-lm-cpp-inference-runtime-quantization-fusion-memory/) - 日期: 2026-04-08T21:52:31+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 LiteRT-LM 在边缘设备上的 C++ 推理运行时，聚焦量化策略配置、算子融合模式与内存管理的工程化实践参数。