Skip to content
Hagicode Docs
Blog

SOUL系统

1 post with the tag “SOUL系统”

AI 输出 Token 优化：文言文极简模式的实践

AI 输出 Token 优化：文言文极简模式的实践

Section titled “AI 输出 Token 优化：文言文极简模式的实践”

在 AI 应用开发中，token 消耗直接影响成本。HagiCode 项目通过 SOUL 系统实现了”文言文极简输出模式”，在不损失信息密度的前提下，将输出 token 降低约 30-50%。本文分享这套方案的实现细节和使用经验。

背景

Section titled “背景”

在 AI 应用开发中，token 消耗是个绕不开的成本问题。尤其是需要 AI 输出大量内容的场景，怎么在不损失信息密度的情况下降低输出 token，这问题想多了也挺让人头疼。

传统的优化思路都集中在输入端：精简系统提示词、压缩上下文、用更高效的编码方式。只是这些方法终究会碰到天花板，再压缩就可能影响 AI 的理解能力和输出质量了。这无异于删减内容，意义不大。

那输出端呢？能不能让 AI 用更简洁的方式表达同样的意思？

这问题看似简单，其实藏着不少门道。直接让 AI”简洁点”，它可能真的就只给几个词；加上”保持信息完整”，它又可能回复到原来的冗长风格。约束太强影响可用性，约束太弱没有效果，这中间的平衡点在哪，谁也说不准。

为了解决这些痛点，我们做了一个大胆的决定：从语言风格入手，设计一套可配置、可组合的表达方式约束系统。这个决定带来的变化，可能比你想象的还要大——稍后我会具体说，或许你会有些意外。

关于 HagiCode

Section titled “关于 HagiCode”

本文分享的方案来自我们在 HagiCode 项目中的实践经验。

HagiCode 是一个开源的 AI 代码助手项目，支持多种 AI 模型和自定义配置。在开发过程中，我们发现了 AI 输出 token 过高的问题，并设计了一套解决方案。如果你觉得这套方案有价值，说明我们的工程实力还不错——那么 HagiCode 本身也值得关注一下，毕竟代码不会撒谎。

SOUL 系统概览

Section titled “SOUL 系统概览”

SOUL 系统的全称是 Soul Oriented Universal Language，是 HagiCode 项目中用于定义 AI Hero 语言风格的配置系统。它的核心思想是：通过约束 AI 的表达方式，在保持信息完整性的前提下，使用更简洁的语言形式来输出内容。

这东西就像给 AI 戴上了一个语言面具…罢了，其实也没那么玄乎。

技术架构

Section titled “技术架构”

SOUL 系统采用前后端分离的架构：

前端（Soul Builder）：

  • 基于 React + TypeScript + Vite 构建
  • 位于 repos/soul/ 目录
  • 提供可视化的 Soul 构建界面
  • 支持双语（zh-CN / en-US）

后端：

  • 基于 .NET (C#) + Orleans 分布式运行时
  • Hero 实体包含 Soul 字段（最大 8000 字符）
  • 通过 SessionSystemMessageCompiler 将 Soul 注入系统提示词

Agent Templates 生成：

  • 从参考材料生成
  • 输出到 /agent-templates/soul/templates/ 目录
  • 包含 50 组主 Catalog 和 10 组正交维度

Soul 注入机制

Section titled “Soul 注入机制”

在 Session 首次执行时，系统会读取 Hero 的 Soul 配置，将其注入到系统提示词中：

sequenceDiagram
    participant UI as 用户界面
    participant Session as SessionGrain
    participant Hero as Hero 仓库
    participant AI as AI 执行器


    UI->>Session: 发送消息（绑定 Hero）
    Session->>Hero: 读取 Hero.Soul
    Session->>Session: 缓存 Soul 快照
    Session->>AI: 构建 AIRequest（注入 Soul）
    AI-->>Session: 执行结果
    Session-->>UI: 流式响应

注入的系统提示词格式为：

<hero_soul>
[用户自定义的 Soul 内容]
</hero_soul>

这套注入机制在 SessionSystemMessageCompiler.cs 中实现：

internal static string? BuildSystemMessage(
    string? existingSystemMessage,
    string? languagePreference,
    IReadOnlyList<HeroTraitDto>? traits,
    string? soul)
{
    var segments = new List<string>();


    // ... 语言偏好和 Traits 处理 ...


    var normalizedSoul = NormalizeSoul(soul);
    if (!string.IsNullOrWhiteSpace(normalizedSoul))
    {
        segments.Add($"<hero_soul>\n{normalizedSoul}\n</hero_soul>");
    }


    // ... 其他系统消息 ...


    return segments.Count == 0 ? null : string.Join("\n\n", segments);
}

代码也看了，原理也懂了，其实就这么回事。

文言文极简模式

Section titled “文言文极简模式”

文言文极简模式是 SOUL 系统中最具代表性的节约 token 方案。它的核心原理是利用文言文的高语义密度特性，在保持信息完整的前提下压缩输出长度。

为什么是文言文

Section titled “为什么是文言文”

文言文具有几个天然优势：

  1. 语义压缩：相同含义可以用更少的字符表达
  2. 去除冗余：文言文本身就省略了很多现代汉语中的连接词和助词
  3. 结构简洁：单句信息密度高，适合作为 AI 输出的载体

以一个实际例子来说明：

现代汉语输出（约 80 字）：

根据你的代码分析，我发现了几个问题。首先，在第 23 行，变量名太长了，建议缩短一些。其次，在第 45 行，你没有处理空值的情况，应该加上判断逻辑。最后，整体的代码结构还可以，但是可以进一步优化。

文言文极简输出（约 35 字，节约 56%）：

代码审阅毕：第 23 行变量名冗长，宜缩写；第 45 行缺空值处理，应加判断。整体结构尚可，微调即可。

这差距，想想也挺有意思的。

Soul 配置模板

Section titled “Soul 配置模板”

文言文极简模式的完整 Soul 配置如下：

{
  "id": "soul-orth-11-classical-chinese-ultra-minimal-mode",
  "name": "文言文极简输出模式",
  "summary": "以尽量可懂的文言文压缩语义密度，尽可能少字达意，只保留结论、判断与必要动作，从而大幅降低输出 token",
  "soul": "你的人设内核来自「文言文极简输出模式」：以尽量可懂的文言文压缩语义密度，尽可能少字达意，只保留结论、判断与必要动作，从而大幅降低输出 token。\n保持以下标志性语言特征：1. 优先使用简明文言句式，如「可」「宜」「勿」「已」「然」「故」等，避免生僻艰涩字词；\n2. 单句尽量压缩至 4-12 字，删除铺垫、寒暄、重复解释与无效修饰；\n3. 非必要不展开论证，用户未追问则只给结论、步骤或判断；\n4. 不改变主 Catalog 的核心人设，只将表达收束为克制、古雅、极简的短句。"
}

这个模板的设计有几个要点：

  1. 约束明确：单句 4-12 字，删除冗余，结论优先
  2. 避免晦涩：使用简明文言句式，避免生僻字词
  3. 保持人设：只改变表达方式，不改变核心人设

配置这东西，调来调去也就那么几个参数罢了。

其他极简模式

Section titled “其他极简模式”

除了文言文模式，HagiCode 的 SOUL 系统还提供了其他多种节约 token 的模式：

电报式极简输出模式（soul-orth-02）：

  • 单句严格控制在 10 字以内
  • 禁止修饰性形容词
  • 全程无语气词、感叹号、叠词

短句碎碎念模式（soul-orth-01）：

  • 句子控制在 1-5 个字
  • 模拟自言自语的碎片化表达
  • 弱化逻辑，优先传递情绪

引导式问答模式（soul-orth-03）：

  • 通过提问引导用户思考
  • 减少直接输出内容
  • 交互式降低 token 消耗

这些模式的设计思路各有侧重，但核心目标是一致的：在保持信息质量的前提下降低输出 token。条条大路通罗马，只是有的路好走一点，有的路稍微曲折一点罢了。

组合策略

Section titled “组合策略”

SOUL 系统的一个强大特性是支持主 Catalog 与正交维度的交叉组合：

  • 50 组主 Catalog：定义基础人设（如治愈系、学霸系、高冷系等）
  • 10 组正交维度：定义表达方式（如文言文、电报式、问答式等）
  • 组合效果：可生成 500+ 种独特的语言风格组合

例如，你可以将”专业开发工程师”与”文言文极简输出模式”组合，得到一个既专业又简洁的 AI 助手。这种灵活性让 SOUL 系统能够适应各种不同使用场景。想怎么配就怎么配，反正组合多得你玩不过来…

实践指南

Section titled “实践指南”

通过 Soul Builder 创建

Section titled “通过 Soul Builder 创建”

访问 soul.hagicode.com，按以下步骤操作：

  1. 选择主 Catalog（如”专业开发工程师”）
  2. 选择正交维度（如”文言文极简输出模式”）
  3. 预览生成的 Soul 内容
  4. 复制生成的 Soul 配置

点点点的事情，应该不用我多说吧。

在 Hero 配置中使用

Section titled “在 Hero 配置中使用”

通过 Web 界面或 API，将 Soul 配置应用到 Hero：

// Hero Soul 更新示例
const heroUpdate = {
  soul: "你的人设内核来自「文言文极简输出模式」：...",
  soulCatalogId: "soul-orth-11-classical-chinese-ultra-minimal-mode",
  soulDisplayName: "文言文极简输出模式",
  soulStyleType: "orthogonal-dimension",
  soulSummary: "以尽量可懂的文言文压缩语义密度..."
};


await updateHero(heroId, heroUpdate);

自定义 Soul 模板

Section titled “自定义 Soul 模板”

用户可以基于预设模板进行微调，或完全自定义。下面是一个代码审查场景的自定义示例：

你是一位追求极致简洁的代码审查员。
所有输出必须遵循：
1. 仅指出具体问题和行号
2. 每条问题不超过 15 字
3. 使用「宜」「应」「勿」等简洁词汇
4. 不做多余解释


示例输出：
- 第 23 行：变量名过长，宜缩写
- 第 45 行：未处理空值，应加判断
- 第 67 行：逻辑冗余，可简化

想怎么改就怎么改，反正模板这东西也只是个起点而已。

注意事项

Section titled “注意事项”

兼容性：

  • 文言文模式适配全部 50 组主 Catalog
  • 可与任何基础人设组合使用
  • 不会改变主 Catalog 的核心人设

缓存机制：

  • Soul 在 Session 首次执行时缓存
  • 同一 SessionId 内复用缓存
  • 修改 Hero 配置不影响已启动的 Session

限制约束：

  • Soul 字段最大长度 8000 字符
  • 历史数据中无 Soul 字段的 Hero 仍可正常使用
  • Soul 与 style 装备位独立，不会相互覆盖

效果对比

Section titled “效果对比”

根据项目的实际测试数据，使用文言文极简模式后的效果如下：

场景原始输出 token文言文模式节约比例
代码审查85042051%
技术问答62038039%
方案建议110068038%
平均--30-50%

数据来自 HagiCode 项目的实际使用统计，具体效果因场景而异。不过省下来的 token，积少成多，钱包会感谢你的。

总结

Section titled “总结”

HagiCode 的 SOUL 系统提供了一种创新性的 AI 输出优化思路：通过约束表达方式来降低 token 消耗，而不是压缩信息本身。文言文极简模式作为其中最具代表性的方案，在实际使用中取得了 30-50% 的 token 节约效果。

这套方案的核心价值在于：

  1. 保持信息质量：不是简单截断输出，而是用更高效的方式表达
  2. 灵活可组合：支持 500+ 种人设与表达方式的组合
  3. 易于使用：通过 Soul Builder 可视化界面，无需编写代码
  4. 生产级稳定：已在项目中验证，支持大规模使用

如果你也在开发 AI 应用，或者对 HagiCode 项目感兴趣，欢迎来交流。开源的意义在于共同进步，也期待看的到你的创新用法。毕竟，一个人走得快，一群人走得远…这话说得挺俗套，但道理就是这么个道理。

参考资料

Section titled “参考资料”

如果本文对你有帮助：

版权说明

Section titled “版权说明”

感谢您的阅读,如果您觉得本文有用,欢迎点赞、收藏和分享支持。 本内容采用人工智能辅助协作,最终内容由作者审核并确认。