夜雨聆风在和大模型的「斗争」中渐渐明晰了大模型的交互本质。
大模型不是传统意义的服务，同样的参数调用返回值很可能是不一样的。
大模型没有记忆，每次交互（发送的请求）要把你需要让大模型那一刻知道的所有信息都带上。
大模型没有状态。不是刚刚处于HAPPY状态，现在又EMO了……
大模型是否能全部理解，如何理解，是否和你预想的反馈一致会因大模型不同而不同。
什么提示词，什么记忆，什么工具，什么skill……都只是一种对不同文本块的概念抽象，对大模型来说没什么区别，大模型只是被训练的对某些标签更「敏感」，更喜欢读文章的开头和结尾罢了（注意力）。
大模型每次阅读的文本有限，因此若要大模型尽量按照你的「预设」反馈，那么如何组织文本就很重要，既要确保信息完整，又要照顾大模型的注意力。
最后，大模型返回什么只是一种概率。绝不能以传统编程思维来预设大模型的返回值。
建「围栏」
大模型要做什么以及怎么做是不可预测的。例如修改文件，Claude Code虽然提供了FileEdit，FileWrite工具，但是依然有几率大模型是通过Bash命令修改文件的。
因此你无法控制大模型要做什么，你只能控制不让大模型做什么。我觉得这就是所谓的Harness。而编程工具能干预结果的地方其实只有一个：tool call（工具调用）。
大模型是无状态的，但编程工具可以有状态。编程工具可以根据自身的状态来对大模型的返回值进行干预，从而校准大模型的行为。
我的构想很简单：用状态机给大模型建围栏。
我将大模型包装成一个对象（Ant），每个Ant都处于一个空间（Space），在每一个Space下定制tool集合。同时还有另外一种特殊的tool来连接两个Space，用来触发Ant从当前Space可以进入目标Space。
运行时Ant一定处于某个Space下，此时就可以干预Ant的行为。例如在技术设计空间内大模型只能写文档，因为没有写文件tool；执行空间内可以写文件，但在调用写文件前也可以干预行为：发现没有调用确认工具则可以拒绝写入。
用一个个定制的Space来约束Ant的行为能力，严格控制转换Space的tool校验。
（未完待续）
