61 lines
3.2 KiB
Markdown
61 lines
3.2 KiB
Markdown
# 前言
|
||
现阶段其他部门都关注于自己工作领域，而忽视了项目全生命周期流程，一些问题往往会在领域交接时产生，之后的章节会逐步展开。在这之前我说这几点：
|
||
- 主Agent与从Agent
|
||
- 项目知识管理
|
||
- 文档&提示词的质量
|
||
- 记忆系统管理 与 Skill
|
||
|
||
## OpenClaw与多Agent
|
||
现阶段因为各种限制不会出现全能性AI，所以建议使用主Agent与多个从Agent的方案。但对于公司而言，All In One的方案并不是最好选择，除了考虑避免All In Boom，还有就有就是记忆、上下文、方便迭代方面的考量。
|
||
|
||
>***另据我所知原生提供Node远程控制方案并且可以自己部署节点的只有OpenClaw。*** 除此之外全球的开源力量使得迭代速度指数级上升，似乎有可能成为新的linux，成为AI时代的agent 中继 Bridge。
|
||
|
||
基于以上几点我选择OpenClaw，以下是我个人建议架构：
|
||
![[主Agent与从Agent.canvas]]
|
||
项目组主要产出文档以及代码，使用主Agent的使用目的主要集中精炼文档、记忆、Skills、沟通其他Agent。
|
||
其他点：
|
||
1. Agent之间的沟通存在token消耗。目前已经我已经找到解决方案准备测试。
|
||
2. 一些相关信息也建议汇总到主Agent中进行汇总，但需要注意使用分层结构，避免出现降智问题。
|
||
|
||
## 知识管理
|
||
现阶段Markdown（之后简称MD） 因为高可读性、高信息密度、纯文本成为AI Agent的文档首选，。我个人推荐Obsidian作为MD的编辑与查看工具，且已有现成的MCP与CLI工具。（还有看板、数据表、画板、导图、流程图等功能）另外个人推荐使用使用git+oss的方式来做版本管理与协作，想简单可以使用SMB。
|
||
|
||
推荐使用多层结构进行管理，避免Context爆炸。这个技巧也可以使用在Skill中。结构参考：
|
||
- AI策划助手_使用说明.md
|
||
- 表结构
|
||
- 道具表说明书.md
|
||
- 道具表说明书_耕种畜牧.md
|
||
- 道具表说明书_加工品消耗品.md
|
||
- 道具表说明书_设施与建筑.md
|
||
- 配表流程
|
||
- skill_开单说明.md
|
||
- skill_配表.md
|
||
|
||
## 记忆系统
|
||
目前已知大致有下面3个流派：
|
||
- 结构化知识图谱派：Evolver
|
||
- 向量检索派：MemorySearch
|
||
- 生成式摘要派：self-improving-agent
|
||
|
||
实际上记忆系统都是混合方案。面向多人的企业级方案才是焦点。
|
||
|
||
### “精耕细作” 式管理记忆
|
||
多人使用场景下，往往会有堆积大量 “噪音”以及错误记忆，尽管有一些工具可以自动优化，但依然建议人工介入，让记忆（经验）更快“收敛”。
|
||
|
||
## 文档&提示词的质量
|
||
某专家策划曾提出以下几个问题：
|
||
1. 能力不同的人，编写的文档，是否会对AI的理解与执行产生较大影响？
|
||
2. 程序需要多加限制还是少加限制？
|
||
3. 什么样的文档适合AI来阅读？
|
||
|
||
我个人认为逻辑清晰认知高的人编写的文档与提示词，AI更容易理解意图并且能够更好的执行；
|
||
程序应该关注每个功能（维度从function => Module)的输入与输出是否正确，所以应该让AI自己发挥除了硬杠杠与主要方向。
|
||
AI写的文档往往比人写的更加简练，更高复用性，所以更适合AI阅读。
|
||
|
||
---
|
||
# 策划
|
||
TODO
|
||
|
||
# 程序
|
||
TODO
|