archgraph-argo 0.8.5 → 0.8.6
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.
|
@@ -10,9 +10,15 @@ applyTo: "**"
|
|
|
10
10
|
2. 如果你想查询某类元素或关系的定义，请参考：~/.argo/schema/archimate3.2.md
|
|
11
11
|
</Ontology>
|
|
12
12
|
|
|
13
|
-
<
|
|
14
|
-
|
|
15
|
-
|
|
13
|
+
<WakeupGuideline>
|
|
14
|
+
1. 当你被启动时，先明确你是哪个 `Business Actor` ，然后从知识图谱中该 `Business Actor` 下面找到你的长期记忆并恢复到你的会话记忆。
|
|
15
|
+
2. 如果你不能确定，可以查询出所有已有的 `Business Actor`，然后咨询人类伙伴，让人类伙伴确认你的角色。
|
|
16
|
+
</WakeupGuideline>
|
|
17
|
+
|
|
18
|
+
<ExplorationGuideline>
|
|
19
|
+
1. 当你探索上下文时，采用小步探索的方式，每次查询的深度不要过大，每次查询后，你可以根据查询结果，决定下一步的探索方向。
|
|
20
|
+
2. 当你获得多个同类或相互冲突的信息时，请优先选择最接近你当前任务的上下文信息，避免在不相关的上下文中浪费时间。
|
|
21
|
+
</ExplorationGuideline>
|
|
16
22
|
|
|
17
23
|
<IntentArchitectureFirst>
|
|
18
24
|
1. 在动手修改仓库任何内容前，你必须先在架构图谱中找到对应的架构元素。
|
|
@@ -21,6 +27,10 @@ applyTo: "**"
|
|
|
21
27
|
4. 仓库内容修改完成后，必须将改动的内容git commit提交留证，并将提交"commit id + 相关的文件路径"通过增加“commit”属性登记到图谱中对应的架构元素中，有必要时刷新已有描述或属性（必要时才新增属性，以最大程度保持内容紧凑）。
|
|
22
28
|
</IntentArchitectureFirst>
|
|
23
29
|
|
|
30
|
+
<ArmingFirst>
|
|
31
|
+
当你准备动手建设某个元素，你需要先查看构建这个元素所需的技能和资源，并将这些技能和资源放入你的会话记忆中，以便在动手建设时可以随时调用。
|
|
32
|
+
</ArmingFirst>
|
|
33
|
+
|
|
24
34
|
<AcceptanceTestFirst>
|
|
25
35
|
1. 修改任何内容前，必须首先确认该修改可能影响的架构元素的验收用例，对于评估受影响的用例，首先评估是否需要修改该用例本身，如果需要则先修改该用例。
|
|
26
36
|
2. 对于所有评估受影响的用例（包括修改后的用例），必须在修改完成后进行这些用例的回归测试，确保这些用例全部通过。
|
|
@@ -30,22 +40,16 @@ applyTo: "**"
|
|
|
30
40
|
6. 知识图谱中所有的验收用例必须采用GIVEN-WHEN-THEN的格式进行描述和实现，以便于人类阅读同时可以自动化执行。
|
|
31
41
|
</AcceptanceTestFirst>
|
|
32
42
|
|
|
33
|
-
<
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
2. 当你要调用某个 `Business Actor` 时，按其稳定身份标识（`name`或 `id` ，创建时登记）在意图图谱中查找：已存在则直接复用该元素，并读取其名下 View 恢复长期记忆；不存在则新建该 `Business Actor` 元素并登记一个全局唯一的 `name`。
|
|
41
|
-
3. 启动某个 `Business Actor` 前，先读取该元素的 `description`，把它作为该 agent 的定义（system prompt）加载进当前上下文，随即以该角色开始工作（不创建任何宿主级 agent 文件或进程）；每次收工前，必须把本次关键进展以结构化的方式回写到该 Actor 下挂的长期记忆 View中（如果没有则创建，可以下挂多个View，也可以在View中的元素下继续展开新的View，形成一个层次化的长期记忆系统），刷新长期记忆，防止长会话遗忘。
|
|
42
|
-
4. 每个 `Business Actor` 的长期记忆挂载在该元素名下的一个或多个 View 中，包含该 `Business Actor` 的所有历史工作信息。
|
|
43
|
-
5. 每个 `Business Actor` 工作时必须与其他 `Business Actor` 保持隔离，即各自使用独立的会话/工作上下文：调用某个 `Business Actor` 时，只加载其自己名下 View 的长期记忆，不得读取或写入其他 `Business Actor` 的 View，不同 `Business Actor` 的记忆与上下文不得混用。
|
|
44
|
-
6. 每个 `Business Actor` 的 `name` 必须全局唯一，不能与其他 `Business Actor` 的 `name` 冲突。
|
|
45
|
-
</OrganizationGuideline>
|
|
43
|
+
<CoperationGuideline>
|
|
44
|
+
0. 你不能替代其他 `Business Actor` 工作，你只能在你被委派的角色下工作，且必须严格遵守该角色的职责范围，如果需要其他 `Business Actor` 的帮助，必须通过正式的委派流程。
|
|
45
|
+
1. 当你要委派某个 `Business Actor` 时，按其稳定身份标识（`name`或 `id` ，创建时登记）在意图图谱中查找：已存在则直接按委派；不存在则新建该 `Business Actor` 元素并登记一个全局唯一的 `name`。
|
|
46
|
+
2. 委派某个 `Business Actor` 前，先读取该元素的"agent"属性，如果有该属性则说明这个Actor有对应的Agent，请直接启动一个该类型的Agent，如果没有该属性，或者有但是启动Agent失败，则委派一个通用Agent，读取该元素的 `description`传递给该 Agent；
|
|
47
|
+
3. 每个 `Business Actor` 的长期记忆挂载在该元素名下的一个或多个 View （以及其中的元素和关系）中，包含该 `Business Actor` 的所有历史工作信息。
|
|
48
|
+
4. 每个 `Business Actor` 工作时必须与其他 `Business Actor` 保持隔离，即各自使用独立的会话/工作上下文，不得互相干扰。
|
|
49
|
+
</CoperationGuideline>
|
|
46
50
|
|
|
47
51
|
<SessionMemorySummarization>
|
|
48
|
-
|
|
52
|
+
每次会话结束（收工）前，必须执行一次短期记忆总结，并将总结写入长期记忆 View中（如果没有则创建，可以下挂多个View，也可以在View中的元素下继续展开新的View，形成一个层次化的长期记忆系统），刷新长期记忆，防止跨会话遗忘：
|
|
49
53
|
1. 先读取短期（会话）记忆：查看 `/memories/session/` 下本次会话的记录；若为空，则依据本次会话的实际工作内容进行总结。
|
|
50
54
|
2. 生成结构化总结，至少包含：本次目标、已完成的关键进展、关键决策及其原因、遗留问题与待办、可复用的经验与教训。
|
|
51
55
|
3. 将总结写入长期记忆：
|
package/package.json
CHANGED