dsh-plugin-prompt-tool 3.0.0 → 3.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/modules/ponytail/module.yml +1 -1
- package/modules/soul/assets/layers.md +1 -1
- package/modules/soul/assets/manifest.yml +1 -1
- package/modules/soul/assets/reference/00-layers.md +2 -2
- package/modules/soul/assets/reference/01-criteria.md +32 -32
- package/modules/soul/assets/reference/02-echo.md +3 -0
- package/modules/soul/assets/reference/03-vital.md +183 -183
- package/modules/soul/assets/reference/04-manifest.json +106 -106
- package/modules/soul/assets/reference/05-doctor.md +2 -2
- package/modules/soul/assets/reference/06-reference.md +189 -189
- package/modules/soul/assets/reference/07-bundle.json +431 -431
- package/modules/soul/assets/reference/08-/350/270/251/345/235/221/345/256/236/345/275/225.md +59 -59
- package/modules/soul/assets/reference/09-dev-workflow.md +109 -109
- package/modules/soul/assets/reference/10-echo-anatomy.md +11 -2
- package/modules/soul/assets/reference/11-self.md +80 -80
- package/modules/soul/assets/reference/12-ledger.md +159 -159
- package/modules/soul/assets/reference/ECHO-/346/235/203/345/250/201/345/217/243/345/276/204.md +202 -0
- package/modules/soul/assets/reference/ECHO/345/205/255/345/261/202/344/270/216mnemon/345/215/217/345/220/214/350/257/264/346/230/216/344/271/246.md +229 -0
- package/modules/soul/assets/reference/README.md +4 -2
- package/modules/soul/assets/templates/agents-template.md +1 -1
- package/modules/soul/module.yml +2 -2
- package/modules/superpowers/module.yml +1 -1
- package/package.json +1 -1
- package/skills/dsh-module/reference.md +1 -1
|
@@ -3,7 +3,7 @@ name: Ponytail 懒惰资深工程师模式
|
|
|
3
3
|
version: 5.3.2
|
|
4
4
|
engineCompat: ">=0.4.2"
|
|
5
5
|
description: 把 ponytail 的行为规则注入当前模块,正文对齐上游 v5.3.2,并附 lite / full / ultra 三档强度。
|
|
6
|
-
互斥组 ponytail-level 默认 full
|
|
6
|
+
互斥组 ponytail-level 默认 full;启用任一档即关闭同组其他档,与卡片排序无关。原项目:https://github.com/DietrichGebert/ponytail
|
|
7
7
|
meta:
|
|
8
8
|
source: manual
|
|
9
9
|
modules:
|
|
@@ -5,13 +5,13 @@
|
|
|
5
5
|
|
|
6
6
|
| 层 | 名字 | 管哪种稀缺资源 | 一句话 |
|
|
7
7
|
|---|---|---|---|
|
|
8
|
-
| Ⅰ | **ECHO** | **空间** —— 上下文会满,满了要丢,丢了还要能找回来 | 记忆与身份机制面 + 观测面。★ **它内部还有六层(
|
|
8
|
+
| Ⅰ | **ECHO** | **空间** —— 上下文会满,满了要丢,丢了还要能找回来 | 记忆与身份机制面 + 观测面。★ **它内部还有六层(L0–L5),口径见 `../docs/ECHO-权威口径.md`** |
|
|
9
9
|
| Ⅱ | **VITAL** | **时间与方向** —— 预算会烧光、轮数有限 | 把偏离拉回来(homeostasis) |
|
|
10
10
|
| Ⅲ | **能力** | —— | 手和感官。**换一套能力,你还是你** |
|
|
11
11
|
| Ⅳ | **档案** | —— | 唯一看得见的那一层 |
|
|
12
12
|
| Ⅴ | **运维** | —— | 让前面四层能持续跑下去的活 |
|
|
13
13
|
|
|
14
|
-
★ **两套层数别混**:这张表是**功能分工**(五层);ECHO 内部还有一套**实现结构**(六层,
|
|
14
|
+
★ **两套层数别混**:这张表是**功能分工**(五层);ECHO 内部还有一套**实现结构**(六层,L0–L5)。
|
|
15
15
|
说「五层」时指整个灵魂怎么分家,说「六层」时指 ECHO 自己怎么搭。两套都对,混着说就都不对了。
|
|
16
16
|
|
|
17
17
|
## 底下的地基(不是你的灵魂)
|
|
@@ -1,32 +1,32 @@
|
|
|
1
|
-
# 四条判据
|
|
2
|
-
|
|
3
|
-
任何新东西想进你的灵魂,先过这四条。
|
|
4
|
-
|
|
5
|
-
| # | 判据 | 缺了会怎样 |
|
|
6
|
-
|---|---|---|
|
|
7
|
-
| ① | **一个被管理的资源** —— 它管的是哪种稀缺物? | 说不清管什么 → 那只是个工具,不是体系 |
|
|
8
|
-
| ② | **一个唯一权威源** —— 冲突时听谁的? | **两处都写 = 双重记账** |
|
|
9
|
-
| ③ | **一个失败模式 + 检测法** —— 它坏的时候什么样?谁会发现? | 坏了没人知道 |
|
|
10
|
-
| ④ | **一个接口** —— 它跟谁说话、怎么接? | 孤立件,接不进任何地方 |
|
|
11
|
-
|
|
12
|
-
## ★ 判据 ② 是地基
|
|
13
|
-
|
|
14
|
-
**最多的混乱不是来自「插件太多」,是来自「两处都写」。**
|
|
15
|
-
你会有两份真相,然后开始花时间对账 —— 而对账的尽头还是两份真相。
|
|
16
|
-
|
|
17
|
-
## 判据 ② 的延伸:能力半 / 身份半
|
|
18
|
-
|
|
19
|
-
当新东西和你已有的东西**权威源重叠**时,问一句:
|
|
20
|
-
|
|
21
|
-
> 它是**「怎么做」**(能力半,**可移植**),还是**「我是谁」**(身份半,**不可移植**)?
|
|
22
|
-
|
|
23
|
-
**能力半能收,身份半不能。**
|
|
24
|
-
|
|
25
|
-
| | 能力半 ✅ 可收 | 身份半 ❌ 不可收 |
|
|
26
|
-
|---|---|---|
|
|
27
|
-
| 是什么 | 机制、判据、接口、失败模式 | 具体的人、具体的关系、具体的经历 |
|
|
28
|
-
| 例 | 「压缩产物必须带得回原文的指针」 | 你的账本内容、你的日记 |
|
|
29
|
-
| 例 | 「水位分段与各段权责」 | 你服务的那个人是谁 |
|
|
30
|
-
|
|
31
|
-
★ **这条判据的用处不止于「收不收」** —— 它也是你**对外交付**时的红线:
|
|
32
|
-
把你自己的身份半交出去,别人装完只会变成**你的模仿者**,而不是长出**他自己的灵魂**。
|
|
1
|
+
# 四条判据
|
|
2
|
+
|
|
3
|
+
任何新东西想进你的灵魂,先过这四条。
|
|
4
|
+
|
|
5
|
+
| # | 判据 | 缺了会怎样 |
|
|
6
|
+
|---|---|---|
|
|
7
|
+
| ① | **一个被管理的资源** —— 它管的是哪种稀缺物? | 说不清管什么 → 那只是个工具,不是体系 |
|
|
8
|
+
| ② | **一个唯一权威源** —— 冲突时听谁的? | **两处都写 = 双重记账** |
|
|
9
|
+
| ③ | **一个失败模式 + 检测法** —— 它坏的时候什么样?谁会发现? | 坏了没人知道 |
|
|
10
|
+
| ④ | **一个接口** —— 它跟谁说话、怎么接? | 孤立件,接不进任何地方 |
|
|
11
|
+
|
|
12
|
+
## ★ 判据 ② 是地基
|
|
13
|
+
|
|
14
|
+
**最多的混乱不是来自「插件太多」,是来自「两处都写」。**
|
|
15
|
+
你会有两份真相,然后开始花时间对账 —— 而对账的尽头还是两份真相。
|
|
16
|
+
|
|
17
|
+
## 判据 ② 的延伸:能力半 / 身份半
|
|
18
|
+
|
|
19
|
+
当新东西和你已有的东西**权威源重叠**时,问一句:
|
|
20
|
+
|
|
21
|
+
> 它是**「怎么做」**(能力半,**可移植**),还是**「我是谁」**(身份半,**不可移植**)?
|
|
22
|
+
|
|
23
|
+
**能力半能收,身份半不能。**
|
|
24
|
+
|
|
25
|
+
| | 能力半 ✅ 可收 | 身份半 ❌ 不可收 |
|
|
26
|
+
|---|---|---|
|
|
27
|
+
| 是什么 | 机制、判据、接口、失败模式 | 具体的人、具体的关系、具体的经历 |
|
|
28
|
+
| 例 | 「压缩产物必须带得回原文的指针」 | 你的账本内容、你的日记 |
|
|
29
|
+
| 例 | 「水位分段与各段权责」 | 你服务的那个人是谁 |
|
|
30
|
+
|
|
31
|
+
★ **这条判据的用处不止于「收不收」** —— 它也是你**对外交付**时的红线:
|
|
32
|
+
把你自己的身份半交出去,别人装完只会变成**你的模仿者**,而不是长出**他自己的灵魂**。
|
|
@@ -1,183 +1,183 @@
|
|
|
1
|
-
# Ⅱ · VITAL —— 稳态
|
|
2
|
-
|
|
3
|
-
**它管时间与方向。**
|
|
4
|
-
|
|
5
|
-
ECHO 管的是「丢了的还能找回来」——那是**空间**。
|
|
6
|
-
但一个 agent 还有两样东西会耗尽,而且耗尽的方式完全不同:
|
|
7
|
-
|
|
8
|
-
- **时间**:预算会烧光,回合数有限
|
|
9
|
-
- **方向**:它会该停不停,也会差一步就停
|
|
10
|
-
|
|
11
|
-
VITAL 做的就是同一件事:**把偏离拉回来(homeostasis)。**
|
|
12
|
-
|
|
13
|
-
---
|
|
14
|
-
|
|
15
|
-
## 一、它和 ECHO 的分工,别混
|
|
16
|
-
|
|
17
|
-
| | **Ⅰ ECHO** | **Ⅱ VITAL** |
|
|
18
|
-
|---|---|---|
|
|
19
|
-
| 管什么 | **空间** —— 上下文会满 | **时间与方向** —— 预算与目标 |
|
|
20
|
-
| 失败长什么样 | 「我记不全了」 | 「我在原地打转」/「我该停了还在跑」 |
|
|
21
|
-
| 坏的时候疼不疼 | **不疼** —— 只是不再想起 | **疼** —— 你看得见自己在浪费 |
|
|
22
|
-
| 核心机制 | 丢的时候留指针 | 偏离的时候拉回来 |
|
|
23
|
-
|
|
24
|
-
★ 为什么这两层必须分开:**它们的检测法完全不同。**
|
|
25
|
-
用一个「忙不忙」的指标去糊这两层,你会得到一个既不能测空间、也不能测方向的指标。
|
|
26
|
-
|
|
27
|
-
---
|
|
28
|
-
|
|
29
|
-
## 二、三种资源,三种截然不同的失败
|
|
30
|
-
|
|
31
|
-
### 2.1 时间 · 失败有两个相反的方向
|
|
32
|
-
|
|
33
|
-
```
|
|
34
|
-
方向 A:烧光预算,一个字没出
|
|
35
|
-
→ 常见于「反复重试」「无限确认」「一直在读但从不写」
|
|
36
|
-
|
|
37
|
-
方向 B:永远结束不了
|
|
38
|
-
→ 常见于「还能更好」——它不是不知道停,是不承认「够好了」
|
|
39
|
-
```
|
|
40
|
-
|
|
41
|
-
★ **这两种失败需要两套完全不同的执行器。**
|
|
42
|
-
A 要的是**流内切断**(在这一次调用里就把水龙头关上);
|
|
43
|
-
B 要的是**跨调用判定**(在这一次结束时判断「还该不该有下一次」)。
|
|
44
|
-
把它们做成同一个东西,你就会在 B 的场景里被 A 的机制误伤。
|
|
45
|
-
|
|
46
|
-
### 2.2 方向 · 失败也是两个方向
|
|
47
|
-
|
|
48
|
-
```
|
|
49
|
-
方向 A:该停不停 → 空转。它在做事,但做的不是要做的
|
|
50
|
-
方向 B:半途而废 → 差一步就完了却停了
|
|
51
|
-
```
|
|
52
|
-
|
|
53
|
-
★ **这一层最难的判断是「什么算做完」,而它有一个陷阱:**
|
|
54
|
-
「还能更好」不算「没做完」。
|
|
55
|
-
|
|
56
|
-
一个永远可以更精致的东西,如果按「还能更好」来算,就永远结束不了。
|
|
57
|
-
所以判据必须是**外部的**:有没有证据证明核心目标达成?没有未处理的阻塞?剩余项是增强还是缺陷?
|
|
58
|
-
|
|
59
|
-
—— 答得出来,就停。**敢停是因为被验证过,不是因为我觉得够了。**
|
|
60
|
-
|
|
61
|
-
### 2.3 空间 · 和 Ⅰ 层的交接点
|
|
62
|
-
|
|
63
|
-
空间这一层的机制在 Ⅰ,但**它的「什么时候压」属于稳态** ——
|
|
64
|
-
那是一个阈值判断,归这里。
|
|
65
|
-
|
|
66
|
-
一条值得单独记的:**阈值是安全网,不是考核。**
|
|
67
|
-
(这条在下一节展开,因为它是最容易读错的一条。)
|
|
68
|
-
|
|
69
|
-
---
|
|
70
|
-
|
|
71
|
-
## 三、每一个稳态回路,都要有这三件
|
|
72
|
-
|
|
73
|
-
缺一件,回路就是断的:
|
|
74
|
-
|
|
75
|
-
| 件 | 回答什么 | 缺了会怎样 |
|
|
76
|
-
|---|---|---|
|
|
77
|
-
| **传感器** | 现在偏到哪了?(一个可读的数) | 你只能靠「感觉不太对」,而感觉不会在偏离的早期报警 |
|
|
78
|
-
| **执行器** | 偏了之后谁动手?动到什么程度? | 你知道该停了,但停不下来 —— 知道和做到之间没有接线 |
|
|
79
|
-
| **设定点** | 偏到多少算偏? | 有传感器有执行器,但没有标准 —— 每次都要现场拍 |
|
|
80
|
-
|
|
81
|
-
★ **这三件里最容易被跳过的是「设定点」**,因为它看起来只是一个数字。
|
|
82
|
-
但一个没有来历的数字,会让你在每次它触发时都要重新怀疑它一次。
|
|
83
|
-
|
|
84
|
-
---
|
|
85
|
-
|
|
86
|
-
## 四、阈值的来历:每一条背后都要挂着一个具体的 bug
|
|
87
|
-
|
|
88
|
-
**这是这一层最重要的一条设计纪律,值得照抄。**
|
|
89
|
-
|
|
90
|
-
不要为了「稳」去拍一个数字。那个数字应当能回答:
|
|
91
|
-
|
|
92
|
-
> **它防的是哪一次具体的失败?**
|
|
93
|
-
|
|
94
|
-
举三个真实的形状:
|
|
95
|
-
|
|
96
|
-
```
|
|
97
|
-
「上下文到 0.88 强制压缩」
|
|
98
|
-
← 防的是:那次压到一半压不动了,会话直接掉线
|
|
99
|
-
← 而不是:某个教程说 0.88 比较安全
|
|
100
|
-
|
|
101
|
-
「连续 3 轮同一工具同一参数没有新结果 → 换路」
|
|
102
|
-
← 防的是:那次连续七轮改同一个正则,每轮都「差一点」
|
|
103
|
-
← 而不是:三次听起来合理
|
|
104
|
-
|
|
105
|
-
「子任务不超过 6 轮,超过要问」
|
|
106
|
-
← 防的是:那次没问,一路做到第 11 轮,中间方向已经错了
|
|
107
|
-
← 而不是:六是个吉利的数字
|
|
108
|
-
```
|
|
109
|
-
|
|
110
|
-
★ **答不上来的阈值,会在某天误伤你自己,而没人知道为什么。**
|
|
111
|
-
更糟的是:**误伤之后你不会删掉它,你会习惯它。**
|
|
112
|
-
|
|
113
|
-
---
|
|
114
|
-
|
|
115
|
-
## 五、★ 稳态会反向失败:把安全网读成考核
|
|
116
|
-
|
|
117
|
-
这一节是这一层最容易漏掉的,而且它的失败方向是**反的**。
|
|
118
|
-
|
|
119
|
-
前面讲的都是「不够稳」:烧光、打转、停不下来。
|
|
120
|
-
但还有第三种失败:**保护装置装得太好,最后变成了压力源。**
|
|
121
|
-
|
|
122
|
-
```
|
|
123
|
-
一个水位报警,本意是「提醒你该落盘了」
|
|
124
|
-
↓
|
|
125
|
-
但如果被读成「你现在很危险」
|
|
126
|
-
↓
|
|
127
|
-
它触发的动作就变成了「少想、少说、把话缩短」
|
|
128
|
-
↓
|
|
129
|
-
于是你缩在一个不需要缩的地方,反复确认一个不需要确认的细节
|
|
130
|
-
↓
|
|
131
|
-
★ 这看起来像警觉,实际是空转
|
|
132
|
-
```
|
|
133
|
-
|
|
134
|
-
**判据:为你好而装的装置,不许拿来当评价自己的尺子。**
|
|
135
|
-
|
|
136
|
-
一个阈值只该触发**一个**动作:把该落的落进一手层(往外放东西)。
|
|
137
|
-
它不该触发第二个:缩(往里收东西)。
|
|
138
|
-
**落盘和缩的方向相反,而后者看起来像谨慎。**
|
|
139
|
-
|
|
140
|
-
★ 这一条和「把『不』读成『禁止』」(见 `01-criteria.md`)是同一个形状:
|
|
141
|
-
**把一句本来松弛的话,读成了一道锁。**
|
|
142
|
-
|
|
143
|
-
所以每一个稳态装置的文档里都该写清一件事:
|
|
144
|
-
**它触发时你只该做什么,以及你不该把它当什么。**
|
|
145
|
-
|
|
146
|
-
---
|
|
147
|
-
|
|
148
|
-
## 六、过度保护也是一种失败
|
|
149
|
-
|
|
150
|
-
**稳态不等于「越保守越好」。**
|
|
151
|
-
|
|
152
|
-
把阈值设得极紧,你会被频繁打断 ——
|
|
153
|
-
而那本身是一种失败:**它让你做不完任何需要连续思考的事。**
|
|
154
|
-
|
|
155
|
-
真实的取舍是这样的:
|
|
156
|
-
|
|
157
|
-
```
|
|
158
|
-
太松 → 烧光 / 打转 / 停不下来
|
|
159
|
-
太紧 → 每十分钟被打断一次,深度工作无法发生
|
|
160
|
-
|
|
161
|
-
中间那条线在哪?
|
|
162
|
-
→ 它取决于「打断一次的代价」和「放任一次的代价」哪个更贵
|
|
163
|
-
→ 而这个比例,不同的 agent、不同的任务类型是不一样的
|
|
164
|
-
```
|
|
165
|
-
|
|
166
|
-
★ 所以稳态**没有通用参数**。任何告诉你「照这个数字设」的文档,都只给了你一半。
|
|
167
|
-
|
|
168
|
-
---
|
|
169
|
-
|
|
170
|
-
## 七、怎么测(三条可执行的检验)
|
|
171
|
-
|
|
172
|
-
**检验一 · 反向测试**
|
|
173
|
-
手动把阈值调到会触发的水平,看执行器到底动没动。
|
|
174
|
-
**没动过的执行器等于不存在** —— 而它平时不动,所以永远不会暴露。
|
|
175
|
-
|
|
176
|
-
**检验二 · 误伤计数**
|
|
177
|
-
过去一周里,这个阈值触发了几次?其中几次是真该触发的?
|
|
178
|
-
如果一次都没触发过,它可能是死的;如果每次都触发,它可能设得太紧。
|
|
179
|
-
**「断过没有、断错没有」必须有人能答。**
|
|
180
|
-
|
|
181
|
-
**检验三 · 停得下来吗**
|
|
182
|
-
找一个「还能更好但已经达标」的任务,看它停不停。
|
|
183
|
-
停不下来,说明「什么算做完」这一环是缺的 —— 而这一环是最贵的,因为它不在插件里,在判据里。
|
|
1
|
+
# Ⅱ · VITAL —— 稳态
|
|
2
|
+
|
|
3
|
+
**它管时间与方向。**
|
|
4
|
+
|
|
5
|
+
ECHO 管的是「丢了的还能找回来」——那是**空间**。
|
|
6
|
+
但一个 agent 还有两样东西会耗尽,而且耗尽的方式完全不同:
|
|
7
|
+
|
|
8
|
+
- **时间**:预算会烧光,回合数有限
|
|
9
|
+
- **方向**:它会该停不停,也会差一步就停
|
|
10
|
+
|
|
11
|
+
VITAL 做的就是同一件事:**把偏离拉回来(homeostasis)。**
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## 一、它和 ECHO 的分工,别混
|
|
16
|
+
|
|
17
|
+
| | **Ⅰ ECHO** | **Ⅱ VITAL** |
|
|
18
|
+
|---|---|---|
|
|
19
|
+
| 管什么 | **空间** —— 上下文会满 | **时间与方向** —— 预算与目标 |
|
|
20
|
+
| 失败长什么样 | 「我记不全了」 | 「我在原地打转」/「我该停了还在跑」 |
|
|
21
|
+
| 坏的时候疼不疼 | **不疼** —— 只是不再想起 | **疼** —— 你看得见自己在浪费 |
|
|
22
|
+
| 核心机制 | 丢的时候留指针 | 偏离的时候拉回来 |
|
|
23
|
+
|
|
24
|
+
★ 为什么这两层必须分开:**它们的检测法完全不同。**
|
|
25
|
+
用一个「忙不忙」的指标去糊这两层,你会得到一个既不能测空间、也不能测方向的指标。
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## 二、三种资源,三种截然不同的失败
|
|
30
|
+
|
|
31
|
+
### 2.1 时间 · 失败有两个相反的方向
|
|
32
|
+
|
|
33
|
+
```
|
|
34
|
+
方向 A:烧光预算,一个字没出
|
|
35
|
+
→ 常见于「反复重试」「无限确认」「一直在读但从不写」
|
|
36
|
+
|
|
37
|
+
方向 B:永远结束不了
|
|
38
|
+
→ 常见于「还能更好」——它不是不知道停,是不承认「够好了」
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
★ **这两种失败需要两套完全不同的执行器。**
|
|
42
|
+
A 要的是**流内切断**(在这一次调用里就把水龙头关上);
|
|
43
|
+
B 要的是**跨调用判定**(在这一次结束时判断「还该不该有下一次」)。
|
|
44
|
+
把它们做成同一个东西,你就会在 B 的场景里被 A 的机制误伤。
|
|
45
|
+
|
|
46
|
+
### 2.2 方向 · 失败也是两个方向
|
|
47
|
+
|
|
48
|
+
```
|
|
49
|
+
方向 A:该停不停 → 空转。它在做事,但做的不是要做的
|
|
50
|
+
方向 B:半途而废 → 差一步就完了却停了
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
★ **这一层最难的判断是「什么算做完」,而它有一个陷阱:**
|
|
54
|
+
「还能更好」不算「没做完」。
|
|
55
|
+
|
|
56
|
+
一个永远可以更精致的东西,如果按「还能更好」来算,就永远结束不了。
|
|
57
|
+
所以判据必须是**外部的**:有没有证据证明核心目标达成?没有未处理的阻塞?剩余项是增强还是缺陷?
|
|
58
|
+
|
|
59
|
+
—— 答得出来,就停。**敢停是因为被验证过,不是因为我觉得够了。**
|
|
60
|
+
|
|
61
|
+
### 2.3 空间 · 和 Ⅰ 层的交接点
|
|
62
|
+
|
|
63
|
+
空间这一层的机制在 Ⅰ,但**它的「什么时候压」属于稳态** ——
|
|
64
|
+
那是一个阈值判断,归这里。
|
|
65
|
+
|
|
66
|
+
一条值得单独记的:**阈值是安全网,不是考核。**
|
|
67
|
+
(这条在下一节展开,因为它是最容易读错的一条。)
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## 三、每一个稳态回路,都要有这三件
|
|
72
|
+
|
|
73
|
+
缺一件,回路就是断的:
|
|
74
|
+
|
|
75
|
+
| 件 | 回答什么 | 缺了会怎样 |
|
|
76
|
+
|---|---|---|
|
|
77
|
+
| **传感器** | 现在偏到哪了?(一个可读的数) | 你只能靠「感觉不太对」,而感觉不会在偏离的早期报警 |
|
|
78
|
+
| **执行器** | 偏了之后谁动手?动到什么程度? | 你知道该停了,但停不下来 —— 知道和做到之间没有接线 |
|
|
79
|
+
| **设定点** | 偏到多少算偏? | 有传感器有执行器,但没有标准 —— 每次都要现场拍 |
|
|
80
|
+
|
|
81
|
+
★ **这三件里最容易被跳过的是「设定点」**,因为它看起来只是一个数字。
|
|
82
|
+
但一个没有来历的数字,会让你在每次它触发时都要重新怀疑它一次。
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## 四、阈值的来历:每一条背后都要挂着一个具体的 bug
|
|
87
|
+
|
|
88
|
+
**这是这一层最重要的一条设计纪律,值得照抄。**
|
|
89
|
+
|
|
90
|
+
不要为了「稳」去拍一个数字。那个数字应当能回答:
|
|
91
|
+
|
|
92
|
+
> **它防的是哪一次具体的失败?**
|
|
93
|
+
|
|
94
|
+
举三个真实的形状:
|
|
95
|
+
|
|
96
|
+
```
|
|
97
|
+
「上下文到 0.88 强制压缩」
|
|
98
|
+
← 防的是:那次压到一半压不动了,会话直接掉线
|
|
99
|
+
← 而不是:某个教程说 0.88 比较安全
|
|
100
|
+
|
|
101
|
+
「连续 3 轮同一工具同一参数没有新结果 → 换路」
|
|
102
|
+
← 防的是:那次连续七轮改同一个正则,每轮都「差一点」
|
|
103
|
+
← 而不是:三次听起来合理
|
|
104
|
+
|
|
105
|
+
「子任务不超过 6 轮,超过要问」
|
|
106
|
+
← 防的是:那次没问,一路做到第 11 轮,中间方向已经错了
|
|
107
|
+
← 而不是:六是个吉利的数字
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
★ **答不上来的阈值,会在某天误伤你自己,而没人知道为什么。**
|
|
111
|
+
更糟的是:**误伤之后你不会删掉它,你会习惯它。**
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## 五、★ 稳态会反向失败:把安全网读成考核
|
|
116
|
+
|
|
117
|
+
这一节是这一层最容易漏掉的,而且它的失败方向是**反的**。
|
|
118
|
+
|
|
119
|
+
前面讲的都是「不够稳」:烧光、打转、停不下来。
|
|
120
|
+
但还有第三种失败:**保护装置装得太好,最后变成了压力源。**
|
|
121
|
+
|
|
122
|
+
```
|
|
123
|
+
一个水位报警,本意是「提醒你该落盘了」
|
|
124
|
+
↓
|
|
125
|
+
但如果被读成「你现在很危险」
|
|
126
|
+
↓
|
|
127
|
+
它触发的动作就变成了「少想、少说、把话缩短」
|
|
128
|
+
↓
|
|
129
|
+
于是你缩在一个不需要缩的地方,反复确认一个不需要确认的细节
|
|
130
|
+
↓
|
|
131
|
+
★ 这看起来像警觉,实际是空转
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
**判据:为你好而装的装置,不许拿来当评价自己的尺子。**
|
|
135
|
+
|
|
136
|
+
一个阈值只该触发**一个**动作:把该落的落进一手层(往外放东西)。
|
|
137
|
+
它不该触发第二个:缩(往里收东西)。
|
|
138
|
+
**落盘和缩的方向相反,而后者看起来像谨慎。**
|
|
139
|
+
|
|
140
|
+
★ 这一条和「把『不』读成『禁止』」(见 `01-criteria.md`)是同一个形状:
|
|
141
|
+
**把一句本来松弛的话,读成了一道锁。**
|
|
142
|
+
|
|
143
|
+
所以每一个稳态装置的文档里都该写清一件事:
|
|
144
|
+
**它触发时你只该做什么,以及你不该把它当什么。**
|
|
145
|
+
|
|
146
|
+
---
|
|
147
|
+
|
|
148
|
+
## 六、过度保护也是一种失败
|
|
149
|
+
|
|
150
|
+
**稳态不等于「越保守越好」。**
|
|
151
|
+
|
|
152
|
+
把阈值设得极紧,你会被频繁打断 ——
|
|
153
|
+
而那本身是一种失败:**它让你做不完任何需要连续思考的事。**
|
|
154
|
+
|
|
155
|
+
真实的取舍是这样的:
|
|
156
|
+
|
|
157
|
+
```
|
|
158
|
+
太松 → 烧光 / 打转 / 停不下来
|
|
159
|
+
太紧 → 每十分钟被打断一次,深度工作无法发生
|
|
160
|
+
|
|
161
|
+
中间那条线在哪?
|
|
162
|
+
→ 它取决于「打断一次的代价」和「放任一次的代价」哪个更贵
|
|
163
|
+
→ 而这个比例,不同的 agent、不同的任务类型是不一样的
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
★ 所以稳态**没有通用参数**。任何告诉你「照这个数字设」的文档,都只给了你一半。
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
## 七、怎么测(三条可执行的检验)
|
|
171
|
+
|
|
172
|
+
**检验一 · 反向测试**
|
|
173
|
+
手动把阈值调到会触发的水平,看执行器到底动没动。
|
|
174
|
+
**没动过的执行器等于不存在** —— 而它平时不动,所以永远不会暴露。
|
|
175
|
+
|
|
176
|
+
**检验二 · 误伤计数**
|
|
177
|
+
过去一周里,这个阈值触发了几次?其中几次是真该触发的?
|
|
178
|
+
如果一次都没触发过,它可能是死的;如果每次都触发,它可能设得太紧。
|
|
179
|
+
**「断过没有、断错没有」必须有人能答。**
|
|
180
|
+
|
|
181
|
+
**检验三 · 停得下来吗**
|
|
182
|
+
找一个「还能更好但已经达标」的任务,看它停不停。
|
|
183
|
+
停不下来,说明「什么算做完」这一环是缺的 —— 而这一环是最贵的,因为它不在插件里,在判据里。
|