把任务结构写进提示词：一个不靠微调的 agent 控制语言

模型接到任务时，第一件事往往不是干活，而是猜你要什么。

一段自然语言指令里，上下文从哪开始、约束有几条、哪个要求优先、输出格式长什么样，全得靠模型从文字里重建。这部分算力花在理解结构上，没有花在推理和执行上。

Reddit 的 r/PromptEngineering 上有个项目叫 Architectural Gravity，盯的就是这个损耗。核心产物 ArcGrav，一个跑在提示词里的 Agent 控制语言：用命名上下文、符号引用、优先级列表和操作指令，把任务结构直接写出来。不需要外部运行时、解析器，也不用针对某个模型做适配或者预训练，普通提示词输入里就能用。

仓库地址是 github.com/ArchitecturalGravity/ArchitecturalGravity，项目页上放了一张结构示意：

作者给了一个故意写复杂的示例，任务是拼出 "Hello World!"：

[Blueprint]:
"""
Char_01: U+0048
Char_02: U+0065
Char_03: U+006C
Char_04: U+006C
Char_05: U+006F
Char_06: U+0020
Char_07: U+0057
Char_08: U+006F
Char_09: U+0072
Char_10: U+006C
Char_11: U+0064
Char_12: U+0021
"""

[CharacterFactory]:
- `value`
=> Create a fresh record whose `value` is the character decoded from the supplied Unicode code point

[Constraint]:
P0. Output only the assembled characters on one line

[Message]: []

Task:
1. Select Char_* entries from [Blueprint] in name order AS [Codes]
2. For each code point in [Codes] in order:
  => Invoke [CharacterFactory] and append its `value` to [Message]
3. Output [Message] ↳
  - Follow [Constraint]

Blueprint 存码点，CharacterFactory 定义一步操作，Constraint 用 P0 标优先级，Task 按序号取数、循环、拼接、输出。整个流程没有一句自然语言描述“请你把字符拼起来”。

作者列出的预期收益有五条：token 消耗和调用成本下降、指令解读歧义减少、执行更一致且不容易越界、跨上下文窗口时漂移更少、响应更快吞吐更高。这些是设计目标，具体数字得看 AgMark 的评测结果。

仓库由四部分组成：

• ArcGrav：语言规范、语法参考、设计原则和可复用的 agent 模式
• AgStudio：本地编辑和分析环境，带结构导航、语法高亮和诊断
• AgMark：基准测试工具，在受控条件下比较不同提示词表示，保留证据和评测结果
• Research：关于模型原生结构表示、解读效率、token 成本和上下文关系的持续研究

有个细节值得注意。示例里那句 “intentionally elaborate”，作者自己承认了：拼一个 Hello World，写了 12 行码点、一个工厂定义、一条优先级约束和三步任务。结构显式化不是免费的，省下的是模型的解读开销，付出的是人写提示词的时间和 token。这笔账在复杂任务里可能划算，在简单任务里基本是亏的。

所以 ArcGrav 真正的看点，不是“新语言”这个名头，而是它把一个问题摆到了台面上：任务结构该由谁来写，写多少，写到什么粒度。作者在帖子里说，长期目标是让模型把更多容量留给推理、验证和执行。这个方向对不对，AgMark 的对比数据比设计文档更有说服力。

给 agent 直接读的参考文档：

• 语言：github.com/ArchitecturalGravity/ArchitecturalGravity/tree/main/ArcGrav/Guide/Agent_References
• 研究：github.com/ArchitecturalGravity/ArchitecturalGravity/tree/main/Research/Agent_References