<!-- title: prompt 当参数：海外三款自调刀 -->
<!-- domain: new-tools -->

国内还在为"换了个模型，prompt 全得重调"熬夜，海外这周连上三把刀，把 prompt 从"手写的咒语"变成"可编译、可回归、可自愈的参数"。6 月 24 日同一天，**dspyer**、**HALO**、**OntoCortex** 三个开源项目一起更新——一个在编译期把你的 Agent 代码转译成可自动调优的 DSPy 程序（自带 benchmark 60%→90%），一个在运行期用专门的 RLM 啃生产 trace、自动给 Cursor/Claude Code 派活改 harness（AppWorld 上 Sonnet 4.6 +15.8 分），还有一个从结构上让 LLM 只许"发意图"、不许"碰执行"。这三把刀指向同一个信息差：**prompt 正在被工程化，而你大概率还在手搓。**

## 先说清楚：为什么"手调 prompt"是个迟早会塌的坑

你在 LangChain / LangGraph 里写的那个 `system prompt`，本质上是一段**没有测试、没有回归、没有版本管理的字符串**。它有三个结构性毛病，dspyer 的作者 Ramkumar M 在 README 里点得很准：

- **Prompt Decay（提示词衰减）**：你把模型从 GPT-4o 升级到 Claude，或者从 Sonnet 4.5 换到 4.6，精心调过的 prompt 当场失效，又得人工重调一遍。
- **Brittle Validations（脆弱校验）**：你写了一堆 `try/except` 去兜底 LLM 吐出来的畸形 JSON、缺字段。
- **No Systematic Tuning（没有系统性调参）**：没法像调超参一样，对着一个数据集自动找出最优的 few-shot 示例和措辞。

国内主流的 Dify、Coze、百度千帆、阿里百炼，解决的是**"可视化编排"**——把节点拖出来连一连，让你少写点胶水代码。但它们几乎都不碰上面这件事：**把 prompt 本身当成一个可以对着数据集自动优化的参数。** 这正是斯坦福 DSPy 这两年在海外的火种，而这周三把刀，分别把这个理念推进到了"编译期""运行期""结构层"三个位置。

## 刀一：dspyer —— 编译期，把 Agent 代码"转译"成可调优程序

- **官网/仓库**：https://github.com/theramkm/dspyer （文档 https://theramkm.github.io/dspyer/）
- **价格**：Apache 2.0，完全免费开源；你只付自己调用的 LLM API 费。
- **最新**：v0.3.5，2026-06-24 发布（当天还在 push）。

DSPy 的核心思想很颠覆：**别手写 prompt，把 prompt 当参数，让优化器对着数据集编译出来。** 但 DSPy 自己有一套 Signature / Predictor / Module 的新语法，迁移成本高，老项目根本搬不动。dspyer 干的事就是当那个"转译器"——你照常用 Python 函数 + Pydantic schema + LangGraph 写代码，它在底下把这些**转译成标准的 `dspy.Module`**，再丢给任何 DSPy 优化器（如 `BootstrapFewShot`）去自动调。

它最值钱的四个能力：

1. **自动自纠正**：用 `@self_correcting` 装饰器，Pydantic 校验一旦失败，自动生成反馈让模型重答，直到符合 schema。不用再手写 `try/except`。
2. **一行调优 + 存盘**：调完的 prompt 可以 `save_prompts("agent_config.json")`，生产环境 `load_prompts` 直接用。换模型？重新 compile 一遍。
3. **数据飞轮**：每次自纠正成功的"输入→输出"对自动落盘成训练集，越跑越能调。
4. **LangGraph 无痛接入**：`from_langgraph(builder, node_mappings=...)` 把现有 StateGraph 整个吃进来，非 LLM 节点原样保留。

作者在自带的情感分类 benchmark 上给出一个很直观的数：**只调推理节点，准确率从 60% 拉到 90%。** 装一行就行：`pip install dspyer`（支持 Python 3.10–3.14）。

**适合谁**：已经在用 LangChain/LangGraph 跑生产 Agent、受够了"换模型就翻车"的 Python 后端和算法工程师。需要提醒一句——它现在还很早期（star 个位数），CI 和测试（69 个用例）做得挺认真，但别直接拍进核心链路，先在旁路 benchmark 上试。

## 刀二：HALO —— 运行期，让 AI 啃自己的生产 trace、自己改自己

- **仓库**：https://github.com/context-labs/HALO （背后是 inference.net，股东之一是做过 Context 编辑器的 samheutmaker）
- **价格**：MIT 开源，本地免费；托管版在 inference.net 另计。
- **热度**：974 stars / 72 forks，比上面两个成熟得多；Desktop 0.1.17、engine 0.1.26，2026-06-24 发布。

如果说 dspyer 是"上线前调好"，HALO 玩的是**"上线后让 Agent 自己进化"**。全称 Hierarchical Agent Loop Optimizer，核心是一个**递归自愈闭环**：

```mermaid
flowchart LR
    A[生产 Agent 跑起来<br/>采集 OpenTelemetry trace] --> B[HALO-RLM 引擎<br/>分解 trace 找共性失败模式]
    B --> C[产出诊断报告<br/>幻觉工具调用/冗余参数/拒绝循环/语义错误]
    C --> D[喂给 Cursor / Claude Code<br/>自动改 harness 代码]
    D --> E[重新部署<br/>再采 trace]
    E --> A
```

HALO 最反直觉的一个判断值得单独拎出来：**用 Claude Code 这种通用 harness 去分析 trace，是错的工具。** 不是模型不够聪明，而是生产 trace 会非常长，通用 harness 容易"过拟合到某一条 trace 的错误"，而不是泛化到 harness 层面的系统性问题。所以 context-labs 专门造了一个 RLM（Reasoning Language Model）来做这件事——它能把"幻觉的工具调用""冗余的工具参数""拒绝循环""语义不对"这些失败模式归因出来，而且**每一条都能直接对应到一个 prompt 编辑**。

数字很硬。在 AppWorld 这个多 App（Spotify、Venmo、文件系统、通讯录）的 Agent benchmark 上，只靠"优化 harness"，不换模型：

| 模型 | dev SGC | 提升 | test_normal SGC | 提升 |
|---|---|---|---|---|
| Gemini 3 Flash | 36.8% → 52.6% | **+15.8** | 37.5% → 48.2% | +10.7 |
| Sonnet 4.6 | 73.7% → 89.5% | **+15.8** | 62.5% → 73.2% | +10.7 |

关键是它用 `dev` split 迭代、用 `test_normal` 验证，证明提升不是过拟合来的。用法对钱包友好：默认用 `gpt-5.4-mini` 跑，trace 总结和上下文压缩这两步（最烧 token 的）单独指定便宜的 `gpt-4.1-nano`，还支持 `OPENAI_BASE_URL` 接任意 OpenAI 兼容服务（OpenRouter、国产兼容端都行）。`pip install halo-engine` 装好，`halo your_traces.jsonl -p "诊断错误并建议修复"` 就能跑。

**适合谁**：已经有线上 Agent、每天产生大量调用、想知道"到底是哪类失败在拖后腿"的团队。流量越大、方差越高，HALO 越有用——这正好是国内 toB Agent 最缺的一层"质检 + 自我迭代"。

## 刀三：OntoCortex —— 结构层，把"意图"和"执行"彻底拆开

- **仓库**：https://github.com/gabert/ontocortex
- **价格**：Apache 2.0 开源；后端 Java 21 / Spring Boot 3.3，前端 Vue 3，LLM 用 Claude。
- **最新**：2026-06-24 还在 push README 和 SECURITY 文档。

前两把刀管"调优"，这把管"**别让 Agent 翻车**"。它的主张叫 **intent-execution separation（意图-执行分离）**：LLM 永远只发出**类型化的意图（SIF，Structured Intent Format）**，只有 7 个动词——`find / create / update / delete / link / unlink / transition`，而且必须用**本体论（ontology）词汇表**里的名字。底下有一个**确定性的执行层**负责校验、路由、翻译、执行。

这件设计买到三样东西，每一样都直击 Agent 落地的痛点：

- **信任反转**：LLM 是"意图路由器"，框架才是"可信执行者"。因为 SIF 被 JSON Schema 圈死，模型**没有任何合法语法能表达 SQL、shell、URL**——所以一个被 prompt injection 或幻觉的模型，根本够不到底层。授权（RBAC/OPA/Keycloak）就插在"LLM 之后、执行之前"这一个确定性点上。
- **后端中立**：LLM 说"我要什么"，框架决定"怎么满足"。同一个本体，可以同时透明地服务 PostgreSQL 和 MongoDB（legal demo 里 `Lawyer` 在 PG、`MatterNote` 在 Mongo，LLM 毫不知情）。
- **"Agent 提议，引擎拍板"**：生命周期由**声明式状态机**管。README 里有个直观例子——用户要在一个 `active` 状态的案子上跑 `Engage` 转换，引擎直接拒绝：`current state 'active' is not in the legal source set [conflict_check]`。模型拿不到 override 权，只能把拒绝解释给用户。

更激进的是它的第二个实验：**一个能跑的业务 App，可能只需要"本体 + 业务规则（纯文本）+ Agent prompt"三样声明式内容，不写任何 service 层代码**。仓库里 legal（律所案件管理）和 vet（兽医诊所）两个域就是这么搭的，换域只换那四五个 YAML/文本文件。

**适合谁**：做企业级、有强审计/合规/权限要求的 toB Agent 的 Java/Spring 团队（国内金融、法律、医疗、政务场景天然契合）。它非常新（star 还是 0），但作为"参考实现"和设计范式，值得早点抄进自己的架构。

## 信息差总结：你知道的 vs 别人在玩的

| 维度 | 国内主流做法（你大概率在这） | 海外这周三把刀 |
|---|---|---|
| prompt 管理 | 手写、放配置文件、换模型靠人肉重调 | **当参数编译**，对着数据集自动优化并存盘（dspyer） |
| Agent 上线后 | 看 dashboard、靠用户投诉发现 bug | **生产 trace 喂给 RLM**，自动诊断并派 Cursor 改 harness、闭环自愈（HALO） |
| Agent 执行 | LLM 直接 function call，校验全靠后置兜底 | LLM 只发**类型化意图 SIF**，确定性层执行，结构上杜绝越权和幻觉（OntoCortex） |
| 可观测/质检 | 基本没有，"Agent 都上岗了，质检层还没人装" | 把 trace 当训练数据，把诊断当回归 |
| 心智模型 | prompt 是"咒语"，靠玄学手感 | prompt 是"代码对象"，可编译、可回归、可自愈 |

## 行动指南：今天就能做的三件事

1. **先体验"prompt 当参数"**：拿你手头一个老 prompt 任务，`pip install dspyer`，跑它 README 里那个 30 秒离线 quickstart（不用 API key、用 mock 模型），亲眼看一次"自纠正"循环怎么把缺字段的输出修好。再跑 `examples/benchmark.py`，看 60%→90% 是怎么出来的。这是认知升级成本最低的一步。
2. **给你的线上 Agent 接一层 trace**：不用立刻上 HALO，先按 OpenTelemetry 标准把 Agent 每一步（assistant message / tool call / tool result）落成 JSONL。有了 trace，HALO（`pip install halo-engine`）随时能 `halo traces.jsonl -p "..."` 开跑。**没 trace，自愈就是空谈。**
3. **抄 OntoCortex 的"意图-执行分离"设计**：哪怕不用它的 Java 实现，也把这个原则搬进自己的架构——**LLM 只产出受 schema 约束的意图，敏感动作走声明式状态机 + 执行前置校验**。这一步直接降低你 toB 场景的合规和安全风险。

一句话收尾：海外正在把 prompt 从"玄学"搬进"工程"，三个位置（编译期 / 运行期 / 结构层）这周都补齐了开源工具。**信息差的窗口期就在这几个月——等 DSPy 范式和 trace 自愈在国内普及，就没你什么事了。**

## 参考来源

- dspyer 仓库与文档：https://github.com/theramkm/dspyer
- HALO 仓库（context-labs）：https://github.com/context-labs/HALO
- OntoCortex 仓库：https://github.com/gabert/ontocortex
- HN Show 本周新品榜（三项目同期上线）：https://news.ycombinator.com/show
- AppWorld Agent benchmark：https://appworld.dev/

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护。
> 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
