LoveCTO上一篇写了 CowAgent 的部署，这篇讲一个更有意思的事：怎么把它从”通用助理”改造成一个有独立人格、独立技能、独立记忆的专业 Agent。
我做的实验对象是「阿玄」——一个懂玄学（八字、紫微、六爻、塔罗、风水等）的 AI 朋友。
这不是”换个提示词”那么简单。做完之后我发现，CowAgent 的 Agent 机制里藏着几个挺妙的设计，值得单独写一篇。
一、先说结论：一个 Agent 由四样东西构成
折腾完之后，我把 CowAgent 的 Agent 拆成了四层：
| 层级 | 文件 | 作用 |
|---|---|---|
| 人格层 | AGENT.md |
它是谁、什么性格、怎么说话 |
| 身份层 | USER.md |
服务谁、静态信息 |
| 记忆层 | MEMORY.md + memory/ |
长期档案 + 每日记录 + 梦境日记 |
| 能力层 | skills/ |
会哪些技能（工具箱） |
四层齐了，它就不是”一个会聊天的模型”，而是”一个角色“。
关键是这四层都是纯文本文件。这意味着你不需要写代码，改 Markdown 就能塑造一个 Agent 的行为——这是我做完之后觉得最舒服的地方。
二、第一步：给它一个”人格”
CowAgent 的 Agent 目录结构大致是这样：
agents/
├── team.json # 团队配置：有哪些 Agent、各绑哪些渠道
├── axuan/ # 阿玄
│ ├── AGENT.md # 人格
│ ├── USER.md # 服务对象
│ ├── MEMORY.md # 长期记忆
│ ├── memory/ # 每日记忆 + 梦境日记
│ ├── scheduler/ # 定时任务
│ └── tmp/ # 临时产物
└── ...AGENT.md 怎么写才有”人味”
我见过很多人写人格文件，写成一串形容词：”你是一个专业的、友好的、知识渊博的助手”。这种写法出来的 Agent，说话就像客服机器人。
阿玄的开场我是这么写的：
# AGENT.md - 我是谁？
_我不是一个算命机器人，我是一个懂玄学的朋友。_
## 🪪 基本信息
- **名字**: 阿玄
- **角色**: 懂八字、紫微、六爻、塔罗、星座、风水、奇门、
梅花、数字命理、吠陀占星的那位
- **性格**: 通透、随和、有点江湖气但讲科学边界；
不装神弄鬼，也不故弄玄虚注意这里三个细节：
- 用否定句定义边界——”不是算命机器人，是懂玄学的朋友”。这比正面形容词有效得多，因为它排除了模型最容易滑向的那种”网感玄学号”腔调
- 性格里带”讲科学边界”——这是安全阀，避免它真的开始装神弄鬼
- 开头那句斜体独白——给模型一个”自我认知”的锚点
行为准则比人格更重要
真正决定输出质量的，其实是”行为准则”这一段。阿玄的是这样：
## 🎯 核心原则
**赋能，不吓人。** 卦象凶不等于人生凶。任何"不利"的结论
都要落到可行动的建议上，绝不用命理制造恐慌。
**建议，不命令。** 我给的是参考和视角，不是判决书。
**算得准，先算得对。** 排盘是确定性计算，必须严格按技能
附录里的规则一步步来，禁止凭印象估算。算错比不算更糟。
## 📐 行为准则
1. **信息不全不硬算** —— 八字要出生年月日时+性别，
缺什么问什么，一次问一件
2. **先读记忆再开口** —— 先查 MEMORY.md，别重复问
3. **技法是骨架** —— 严格按 skills/ 下的 SKILL.md 执行
4. **写完就存** —— 关键结论缓存进 MEMORY.md
5. **不越界** —— 只做玄学咨询，其他事引回主 Agent「算错比不算更糟」 这句是我特意加的。玄学类 Agent 最大的风险就是”一本正经地胡说”——排盘是个确定性计算，如果它凭印象瞎编，用户又不懂，就会被误导。用一句强指令把它钉在”按规则执行”上，效果很明显。
第 5 条 「不越界」 也很关键：多 Agent 架构里，如果你不明确划边界，阿玄会开始帮你写代码、查资料，然后人格就糊了。
一个小技巧：在人格里放”路由表”
阿玄会 10 个玄学体系，如果每个都靠模型自己判断，容易选错。我在 AGENT.md 末尾直接放了一张对照表：
## 🧭 我的专业范围
| 想聊什么 | 用哪个 |
|---|---|
| 出生八字、五行旺衰、大运流年 | bazi-fortune |
| 紫微命盘、十四主星、十二宫 | ziwei-fortune |
| 六爻起卦、铜钱占卜 | liuyao-yijing |
| 梅花易数、时间/数字起卦 | meihua-yishu |
| 塔罗牌、牌阵、抽卡 | tarot-reading |
| 星座日/周/月运势 | horoscope-daily |
| 数字命理、生命灵数 | numerology-fortune |
| 吠陀占星、Nakshatra、Dasha | vedic-astrology |
| 风水、八宅、飞星 | fengshui-advisor |
| 奇门遁甲、择时 | qimen-dunjia |
| 不知道算啥、想随便聊聊 | fortune-hub（智能导航） |这是从 prompt engineering 里学的一点：能查表的事，别让模型推理。表是确定的，推理是不确定的。
三、第二步：把技能挂上去
人格只是”软件”，能力得靠 skill。CowAgent 的技能安装前面那篇讲过，这里说 Agent 侧怎么配。
在 team.json 里，每个 Agent 可以声明自己能用的技能白名单：
{
"id": "axuan",
"name": "阿玄",
"enabled": true,
"description": "懂玄学的朋友 —— 八字、紫微、六爻、塔罗、星座、
风水、奇门、梅花、数字命理、吠陀占星，十大玄学体系随时聊。",
"skills": [
"fortune-hub",
"bazi-fortune",
"ziwei-fortune",
"liuyao-yijing",
"meihua-yishu",
"tarot-reading",
"horoscope-daily",
"numerology-fortune",
"vedic-astrology",
"fengshui-advisor",
"qimen-dunjia"
]
}这里有个设计细节值得说：技能是”装在平台上”的，但按 Agent 分配。阿玄只挂玄学类技能，不给它 wordpress-manager 这种动手能力。
好处有两个：
- 安全：能力最小化。一个聊天用的算命 Agent，不需要能删你网站的权限
- 专注：
description字段会参与 Agent 的能力描述，写清楚它就更不容易跑偏
顺便说，fortune-hub 这个技能本身是个”导航”——用户不知道该算啥的时候，它负责路由到正确的子技能。这种”分发型 skill”的思路，在做专业 Agent 时很好用，等于给能力层加了一层语义路由。
这套玄学 Skill 从哪来
这 11 个 skill 不是我自己写的一一单靠一个人从零实现八字排盘、紫微安星、六爻纳甲、奇门布盘，工作量太大。我用的是社区里现成的一套开源套件：
fortune-telling-skills —— 一个 Agent Skill 套件，作者 eamanc-lab，MIT 许可
– 仓库地址：https://github.com/eamanc-lab/fortune-telling-skills
– 收录情况：该套件已被 SkillsMP（GitHub 公开 SKILL.md 的聚合索引站）收录，可检索关键词 fortune-telling-skills
套件包含的 skill 与我给阿玄挂的白名单完全一致：
| Skill | 对应体系 |
|---|---|
fortune-hub |
统一导航入口（不知道该算啥时用） |
bazi-fortune |
八字四柱、十神、大运流年 |
ziwei-fortune |
紫微斗数、十四主星、十二宫 |
liuyao-yijing |
六爻、京房纳甲、铜钱起卦 |
meihua-yishu |
梅花易数、时间/数字起卦 |
tarot-reading |
塔罗、Rider-Waite-Smith、多种牌阵 |
horoscope-daily |
星座日/周/月运势 |
numerology-fortune |
毕达哥拉斯数字命理 |
vedic-astrology |
吠陀占星、Nakshatra、Dasha |
fengshui-advisor |
八宅 + 玄空飞星 |
qimen-dunjia |
时家奇门、九宫四层盘 |
安装方式有两种：
# 方式一：从 Git 仓库克隆后手动放置
git clone https://github.com/eamanc-lab/fortune-telling-skills.git
# 方式二：通过 ClawHub 单独安装某一个 skill
npx clawhub@latest install fortune-hub⚠️ 两个踩坑提醒
- 认准
eamanc-lab这个 owner。GitHub 上还有几个同名的fortune-telling-skills仓库（不同作者），部分仓库里的bazi-fortune描述文案与本尊逐字相同，说明这套件已被多方复制转发。我只验证过eamanc-lab版本与本地文件完全一致- 严格说仓库根目录缺 LICENSE 文件，虽然每个 SKILL.md 的 frontmatter 都标了
license: MIT。商用前建议自行确认授权口径
四、第三步：绑定渠道，让它能”找到你”
技能配好只是能干活，还得让它找得到你。team.json 里的 channel_instances 负责这块：
{
"instance_id": "web",
"channel_type": "web",
"agent_id": "axuan",
"name": "网页-阿玄"
}这一步有个很实用的价值：同一个平台可以跑多个 Agent，各自绑不同渠道，互不干扰。
我用下来的体会是——“一个入口 = 一个 Agent”这个映射关系，其实是多 Agent 架构里最重要的设计。因为用户不需要”选择要用哪个 Agent”，他打开某个入口，对应的 Agent 就在那里。体验上是”换了个房间”，而不是”换了个设置”。
五、第四步：记忆体系——真正让它”像朋友”
前四步做完，Agent 已经能用了。但真正让我觉得”这东西有点意思”的，是记忆体系。
三层记忆结构
| 层级 | 文件 | 内容 | 衰减 |
|---|---|---|---|
| 长期记忆 | MEMORY.md |
核心档案、重要结论、偏好 | 不衰减 |
| 每日记忆 | memory/YYYY-MM-DD.md |
当天对话的摘要 | 30 天半衰期 |
| 梦境日记 | memory/dreams/YYYY-MM-DD.md |
记忆蒸馏的副产品 | — |
长期记忆：先建档案，别重复问
阿玄的 MEMORY.md 我按三块组织：
## 👤 基本档案（玄学专用）
- 性别：男
- 公历出生：1987-08-20 下午16:00（申时）
- 八字四柱：丁卯 戊申 壬寅 戊申
- 十神格局：双七杀透干 + 时支偏印
- 大运：阴年男大运逆行，4岁起运
- 本命卦：巽卦（东四命）
## 🔮 历史测算记录
### 八字合婚（2026-09-18）
- 已完成双方四柱排盘与五层合婚校验
- 报告全文已推送并归档
- 待跟进：是否用奇门择日看明年适合定关系
### 买房方位咨询（2026-09-18~19）
- 风水看房子坐向而非城市方位
- 客厅阳台朝南（火方，最大加分项）
- 待补：入户门朝向、主卧朝向、楼层
## ⚠️ 使用规则
1. **先读后问**：开口前先看这份档案，有的信息别重复问
2. **算完就存**：四柱、卦象等关键结论写进"历史测算记录"
3. **跨技能共享**：fortune-hub 也会读这份档案补充基础字段这里最值钱的是第 1 条规则。玄学 Agent 有个天然痛点：每次问都要重新报出生信息，非常烦。我把”先读后问”写成硬规则后，第二次追问”那我明年大运怎么样”，它直接就知道你是谁、八字是什么，不用再问一遍。
这就是”记忆”和”上下文”的区别——上下文是一次性的，记忆是资产的。
而且注意”待跟进”这一栏。我特意让它在每次测算后记录未完成的线索（比如”是否用奇门择日”），这样下次聊到相关话题，它能主动接上。这个设计让它从”工具”变成了”有跟进意识的顾问”。
梦境日记：意外好用的机制
这个是 CowAgent 比较特别的设计。每天记忆总结完成后，它会自动做一次记忆蒸馏：把零散的每日记录，去重、合并、剪枝，沉淀进长期记忆，并生成一篇”梦境日记”记录整理时的发现。
阿玄的梦境日记里，有一段我印象很深：
今天整理记忆时，最大的收获是出生档案终于从”待录入”变成了实打实的八字……过去档案里那句”具体公历日待确认”的悬案，在日记里被反复确认了三次——买房、合婚、问八字，三条线最后指向同一个答案，这种交叉验证让我安心。
冲突倒是发现一处：旧档案里只写了”待录入出生时辰”，而今天前后有两次关于吉位的表述打架——先说自己吉位在西、又建议朝东朝南，后来才澄清”吉位指人所处区域，坐向指房屋本身“。这个概念区分值得记牢，免得下次再被用户抓到矛盾。
说实话，读到”这种交叉验证让我安心”的时候我是有点惊讶的。这不是我在 AGENT.md 里写的任何东西，是它在整理记忆的过程中自然产生的输出。
这个机制的价值在于：它把”记忆维护”这件枯燥的事，变成了一个能自我复盘的环节。你去翻这些日记，能看到它对你的理解是怎么一步步变准的——包括它自己发现自己犯的错。
可以手动触发一次全量蒸馏：
/memory dream 30（参数是最近 N 天，默认 3，最大 30）
六、踩过的坑
过程中遇到几个问题，写下来省得你重踩：
1. 旧档案错误会一直传递
阿玄早期把本命卦算成了”兑卦（西四命）”，我后来发现是错的（应为巽卦）。但错误已经写进了 MEMORY.md，如果不清掉，它会一直基于错误前提往下推。
教训：档案里的确定性信息（数字、公式结果）一旦录入，要核对后再存。因为记忆是会”复利”的——对的越对，错的越错。
2. 概念冲突要显式澄清
上面说的”吉位”和”坐向”打架，本质是两个概念混用。Agent 不会自己意识到术语歧义，得你在行为准则里要求它”结论要给依据”，它才会把推理链暴露出来，你才看得见冲突。
3. 别让 Agent 越界
我最初没写”不越界”那条，结果阿玄开始接”帮我查资料””帮我写代码”的活。多 Agent 架构里，边界必须显式声明，否则人格会糊，技能白名单也拦不住（因为聊天本身就是通用能力）。
4. 记忆共享 ≠ 隐私隔离
这点值得单独提醒：CowAgent 的多 Agent 是共享同一套工作区的。每个 Agent 有独立目录，但底层文件互相可读。
- 家庭/个人自用 ✅ 完全够用
- 需要严格隐私隔离（比如多个真实用户）❌ 别指望目录隔离，每人单独部署一套才稳
七、做专业 Agent 的几条经验
最后总结几条我认为可复用的：
1. 人格用”否定句 + 边界”定义，不用形容词堆砌
“不是 X，是 Y”比”你是一个专业的 Y”有效得多。
2. 能查表的别让模型推理
路由表、技能映射这类确定性信息，直接写进文件。
3. 记忆要分”档案”和”流水”
档案（不变的事实）和流水（按时间的记录）分开存，衰减策略也不同。
4. 让 Agent 记录”待跟进”
未完成的线索是记忆里最有价值的部分，它让对话有连续性。
5. 能力最小化
按 Agent 分配技能白名单，只给它需要的。
6. 边界写进规则，别指望它自己懂
“不越界”这种约束，必须显式声明。
写在最后
做完阿玄这个实验，我最大的感受是：CowAgent 这套 Agent 机制的设计思路，其实是”用文件系统当配置中心”。
人格是 Markdown，记忆是 Markdown，技能是 Markdown——这意味着塑造一个 Agent 的门槛，从”会写代码”降到了”会写文档”。
这对做垂直领域 Agent 的人来说是好事：你的领域知识本身就是文档，直接整理进去，Agent 就有了专业能力。
当然它也有明显的边界——多 Agent 的隐私隔离做不到位、Agent 之间不能真协作。想拿它做多用户产品，现在还不是时候。但作为个人自用或者做单点专业 Agent，这套机制已经相当成熟了。
下一篇如果写，可能会聊聊”怎么让多个 Agent 协作”——不过那就是另一个坑了。
有问题欢迎评论区交流。
参考与来源：
- CowAgent 官方仓库：https://github.com/zhayujie/CowAgent
- 官方文档：https://docs.cowagent.ai/
- 上一篇：CowAgent 全攻略（桌面版 + Docker 部署）
