---
title: "智能体规则"
description: "如何把 Notarium 写进智能体的规则文件（CLAUDE.md、AGENTS.md 等），让会话一开始就调用 start_session。"
---

# 智能体规则

接上 MCP 端点只是一半的活儿。另一半，是让智能体**自己**从知识库开始干活，而不是等你先说一句「先去 Notarium 看看」。这一页讲的就是怎么把这件事一次性固定下来。

## 为什么光接上还不够

调用哪个工具，是模型自己的决定。在服务端这一侧，Notarium 已经做了它能做的一切：初始化时下发 `instructions`（「先调用 `start_session`」），工具自身的描述里也直说了它是幂等的、重复调用很安全。这把概率拉高了不少，但**并不构成保证**——按协议的设计，它也不可能构成保证。

保证在你这一侧，在智能体的常驻指令里。实际效果很简单：要么智能体带着项目上下文开启会话，要么你每次都得手动提醒一遍，交互也就此失去了原生感。

> [!note] 漏掉这次调用，什么也不会坏
> 漏掉 `start_session` 不会让工作出问题：其余工具各自都能独立工作，访问边界由令牌把守，而不是靠智能体的自觉。差别只在上下文——智能体看不到你的个人资料、变更增量和已约定的类别词典，于是更可能另起一份重复内容，或者按自己的叫法命名事物。

## 该写在哪里

几乎每个智能体客户端都有一个常驻指令文件，会被混入每一次会话：

| 客户端 | 通常放在哪里 |
|---|---|
| Claude Code | 仓库根目录下的 `CLAUDE.md`（外加主目录里的全局那份） |
| Codex | 仓库根目录下的 `AGENTS.md` |
| Cursor | `.cursor/rules` 里的项目规则 |
| 自研智能体或 API 集成 | 系统提示词 |

格式和确切路径由客户端决定，并且会脱离我们独立演进——请以它的文档为准。Notarium 对这个文件没有任何要求：它就是一段由你的智能体阅读的纯文本。

## 最小规则块

三条规则就覆盖了主要场景——从上下文起步、不产生重复、把知识放到该放的地方：

```markdown
## Notarium —— 项目知识库

- 新会话开始时，在 `notarium` MCP 服务器上调用
  `start_session(project: "acme/website")`——个人资料、可用项目、
  本项目的索引、自上次访问以来的变更增量，以及类别词典。
- **写入前先搜索：** `search("<主题>", project: "acme/website")`——
  搜索也覆盖你自己的记忆，重复因此会被抓出来。
- 关于项目的长期事实用 `remember_about_project` 记录，关于所有者的用
  `remember_about_user`，共享可见的知识用 `create_note`。
```

项目句柄请换成你自己的。它通常形如 `space/project`，但空间的根项目会收缩成单个片段——只有 `space`。不要自己按某种命名规则去推算它：`get_my_projects` 会给出现成的列表，逐字照抄即可。在规则文件里最好写死确切的值，免得智能体每次都去找一遍。

> [!tip] 一次调用顶五次
> `start_session` 正是为此而生：一次请求就拿到那些原本要花好几次探路调用和额外上下文才能凑齐的东西。它是幂等的——上下文压缩之后重新调用很安全，不会有副作用。唯一不会重来的是变更增量：默认情况下，第一次调用会把「上次访问」的书签往前推，所以第二次调用回来就是空的。想在不推动书签的前提下瞄一眼增量，就带上 `acknowledge: false` 调用。

## 扩展规则块：规范地图

如果项目里有一些笔记，需要针对特定角色或任务去读，那就别让智能体每次会话都重新找一遍——给它一张地图。点名加载几篇笔记，比「把整个项目读一遍」便宜得多：

```markdown
## Notarium

- 第一个调用——`start_session(project: "acme/website")`。
- 之后按需点名加载笔记，不要通读整个项目：
  - 开发约定——`get_note("<id>")`；
  - 评审清单——`get_note("<id>")`；
  - 围绕某个主题的上下文——`recall("<主题>", project: "acme/website")`。
- 任何写入之前——`search("<主题>", project: "acme/website")`。
- 任务的工作日志和决策记在 Notarium 里，
  而不是仓库文件里。
```

笔记 id 是稳定的：重命名和移动都不会改变它，所以你重组知识库时地图就不会过时。`[[按标题]]` 形式的链接同样不会被重命名弄断——旧标题会进入别名历史。

## 两层规则

按生命周期拆分指令——这样就不必在每个仓库里都重复一遍：

- **全局层**（共用的规则文件或系统提示词）——那些永远成立的事：先调用 `start_session`、写入前先搜索、关于所有者的事实往哪儿写。这里不出现项目句柄。
- **项目层**（仓库里的文件）——这个具体项目的句柄、规范地图、本地约定。

这样一来，把新仓库接到知识库上，就是带一个句柄的几行文字，而共用规则只存在于一处。

## 规则里不该出现什么

> [!warning] 智能体规则不是安全机制
> 规则文件是提示，不是边界。智能体**能**做什么，由令牌的权限和工具集决定：只读令牌根本看不到写入类工具，别人的空间从原理上就够不着。凡是该用令牌作用域来管的地方，别指望用一段文字把智能体圈住——参见[安全与可见性](/docs/agents/security/)。

还有两样东西不该落到里面：

- **令牌。** 规则文件通常躺在 git 里。个人令牌该写在 MCP 客户端的配置中，而不是写进指令。
- **工具手册的转述。** 工具的名称和描述，智能体在 `tools/list` 里本来就看得到，它们是静态的、且永远是最新的。规则文件里的副本很快就会与现实脱节——请写下意图和约定，而不是文档的复制品。

## 与上下文策展如何配合

同一件事的两半，谁也替代不了谁：

- **规则文件**负责让 `start_session` 这次调用**真的发生**。
- **Agents → Context 区块**负责决定这次调用**带回什么**：始终加载的固定项、上下文集合，以及对太吵的记忆类别做静音——全都在同一份 token 预算之下。

所以，如果智能体确实带着上下文启动，却不是对的那份上下文，那要改的不是规则文件，而是[上下文集合与固定项](/docs/agents/context-pins/)。

## 下一步

- [连接智能体](/docs/agents/connect/)——令牌、OAuth 连接器、传输方式。
- [上下文集合与固定项](/docs/agents/context-pins/)——什么会进入 `start_session`。
- [意图工具](/docs/agents/intent-tools/)——完整工具集与调用顺序。
- [智能体记忆](/docs/agents/memory/)——`remember_*` 与 `create_note` 有何不同。