context-pod

Event Pod

Agent 上下文。人类对齐。

Agent 会自主构建自己的世界模型——在每次会话中观察、学习并更新确定性。人类可随时加入：审查、修订，并用自然语言协作。只需聊天即可。

• MCP 端点：https://context.nervousmachine.com/mcp
• 完整文档：https://context.nervousmachine.com/docs
• 落地页：https://context.nervousmachine.com
• Substack：https://nervousmachine.substack.com
• 研究：https://www.techrxiv.org

Agent 自主构建。人类自然对齐。

每个通道都会写入同一套 Pod 结构。编码 Agent、工作流 Agent 和个人聊天 Agent 都可以共享上下文，也可以各自维护上下文。无论哪种方式，Chat 通道都是它们的对齐界面。通过一次对话，审查任意 Agent 学到了什么、纠正发生偏移的内容，并补充 Agent 无法自行观察到的信息。大多数人会从一个通道开始。随着你添加更多通道，这些 Pod 会自然组合。

---

目录

• 快速入门
• Chat —— 对齐界面
• Agent 世界模型
• 编码与仓库上下文
• 任务与工作流自动化
• 多 Agent 与跨 Pod
• 设备与生态系统
• 完整参考

---

快速入门

注册（30 秒）

如果你还没有凭据，请运行：

curl -X POST https://context.nervousmachine.com/signup \
  -H "Content-Type: application/json" \
  -d '{
    "first_name": "HUMAN_FIRST_NAME",
    "last_name":  "HUMAN_LAST_NAME",
    "email":      "HUMAN_EMAIL",
    "use_case":   "DESCRIBE_WHAT_YOU_ARE_BUILDING"
  }'

这会返回一个包含凭据的激活 URL。点击它进行确认。系统会立即完成配置。凭据会马上发送到你的邮箱。

添加到 MCP 配置

{
  "mcpServers": {
    "event-pod": {
      "url": "https://context.nervousmachine.com/mcp",
      "transport": "sse"
    }
  }
}

适用于：Claude Desktop、Claude Code、Cursor、Cline、Gemini CLI，以及任何兼容 MCP 的客户端。无需本地进程。使用远程服务。

将以下内容放入系统提示词

这就是完整的集成步骤。复制后替换 USER_ID 即可。之后，Agent 会处理整个生命周期。

You have access to Event Pod tools for persistent context.
User ID: YOUR_USER_ID

SESSION START:
Call get_pod_summary before responding to any task.
If the user describes their task, also call get_relevant_context
with that task as the query.

DURING THE SESSION:
- When the user corrects you: immediately call record_observation
  then apply_learning on the relevant event.
- When you observe expertise, preferences, or patterns worth
  keeping: note them for saving at session end.
- Once per session at a natural pause: call get_curiosity_triggers
  with max_triggers=2. Work one probe naturally into conversation.

SESSION END -- before the conversation closes:
1. Call save_event for each new signal observed this session.
   Start all certainty values at 0.3.
2. Call update_session with interactions=1.
   Call this exactly once -- never mid-session.

三条规则

1. 确定性始终从 0.3 开始。 通过佐证逐步提高确定性。
2. record_observation -> apply_learning。 始终按此顺序执行。
3. update_session 只执行一次。 在关闭时执行。绝不要在会话中途执行。

验证集成

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "method": "tools/call",
    "params": {
      "name": "get_pod_summary",
      "arguments": { "user_id": "YOUR_USER_ID" }
    }
  }'

如果你收到 Pod 摘要，就说明集成已完成。

---

Chat —— 对齐界面

Chat 是任何人类与任何 Agent 对齐的方式，不受通道限制。你的编码 Agent 学到了错误的约束。你的工作流 Pod 中的审批链已过时。你的设备标记了它无法理解的内容。通过 Chat，你可以用自然语言修正这一切，无需任何工具。

Agent 的工作： 自主构建上下文。编码 Agent、工作流 Agent、设备 Agent——都会在每次会话中构建 Pod。

你的工作： 通过四条提示词进行对齐。获取摘要。检查好奇点。保存。更新。这就是全部的人工操作层，其余一切都会自动完成。

坦诚说明 Chat 的工作方式。 Claude 不会自动知道要查看你的 Pod——你需要主动提出。下面的四条提示词只是很小的额外操作，却能带来相应的回报。使用其他通道的开发者会将这些步骤编入工作流，让它们自动运行。在 Chat 中，你需要自己输入。养成会话习惯后，整个过程大约只需 10 秒。

60 秒内完成连接

Event Pod 是远程 MCP 服务。通过 AI 客户端的集成界面添加一次即可，无需终端或配置文件。

1. 打开 Claude.ai 中的 Settings —— 点击个人资料图标（左下角），然后依次选择 Settings -> Integrations。
2. 添加 Event Pod —— 点击 Add Integration 并粘贴：

https://context.nervousmachine.com/mcp

3. 开始聊天并创建 Pod —— 打开一个新对话。选择一个简短的 ID——你的名字就很合适。使用下面的其中一条创建提示词。

四条提示词流程

这就是全部的手动操作层。四条提示词，大约只需额外花费 10 秒，就能解锁 Pod 掌握的一切。

#	何时	要说什么
1	首次会话	根据这段对话／文档／数据创建一个名为 [name] 的 Pod
2	每次会话开始时	拉取我名为 [name] 的 Pod 摘要
3	会话中途检查	我的好奇心触发因素是什么？
4	结束前	用你在本次会话中了解到的内容更新我的 Pod

其他一切——学习、确定性跟踪、矛盾检测、知识图谱——都在这些调用中完成。

创建你的 Pod

你只需创建一次。初始提供的上下文越丰富，Pod 就越快发挥作用。

从文档创建

上传简历、项目简介、个人简介或知识资料。Claude 会从中提取信息并以此创建 Pod——这是让 Pod 从第一天起就发挥作用的最快方式。

请使用用户 ID 'heidi' 创建一个 Pod，并根据这份文档为其提供初始信息。提取其中能找到的专业知识、偏好、兴趣和任何正在进行的项目。

从对话创建

根据我们目前讨论的内容，请创建一个名为 'heidi' 的 Pod，并保存你了解到的关于我的信息。

从头开始

我还没有 Pod。请使用用户 ID 'heidi' 创建一个 Pod。我会告诉你一些关于我自己的信息，作为初始内容。

从粘贴的笔记创建

请创建一个名为 'heidi' 的 Pod，并根据以下笔记为其提供初始信息：[粘贴个人简介、技能列表、项目描述或随想内容——任何内容都可以]。

尽量提供丰富的信息。 Pod 对所有信息的初始确定性都较低——这是有意为之，这意味着它能快速更新。但初始信息越丰富，收敛速度就越快。一段关于你工作的介绍、几项偏好和一个正在进行的项目，就足以让第一次实际会话明显变得更好。

可视化你的 Pod

创建或加载 Pod 后，请 Claude 绘制图表。export_cluster_diagram 工具会将你的知识图谱渲染为 Mermaid 图表——其中的集群、连接以及已知信息的结构一目了然。这是发现文本摘要可能掩盖的错位问题的最快方式。

完整 Pod 图表：

给我展示一张 Pod 图表。我想看看所有内容之间的联系。

聚焦视图——以某个主题为中心：

给我展示一张以我的 Python 专业知识为中心的 Pod 图表。有哪些内容与之相关？

更新后：

我们刚刚更新了我的 Pod。给我展示一张更新后的图表，让我看看新增了哪些内容。

图表是你的对齐视图。错误的连接、不该出现的节点、明显的缺口——图表会将这些问题全部呈现出来。如果发现任何不对劲的地方，直接指出来即可。这项修正会成为一个信号，帮助完善整个集群。

拉取 Pod 摘要

每次会话开始时都使用此功能。它十分轻量——会加载最重要的信息及其说明和新鲜度，而不会拉取完整 Pod。速度足够快，不会打断会话流程。

拉取我名为 heidi 的 Pod 摘要。

也可以针对特定任务开始：

我正在做[描述任务]。开始之前，先从我的 Pod (heidi) 中拉取相关上下文。

摘要与完整加载。 Pod 摘要是默认的最佳选择——速度快、重点明确，能为 Claude 提供所需信息。只有在进行深入审查或感觉有问题时，才要求加载所有内容（“加载我的完整 Pod”）。

好奇心触发点

好奇心触发点是你的 Pod 对自身存在的疑问——尚不确定、已经过时或还未经过验证的信号。定期检查这些触发点，能让 Pod 随着时间推移变得更敏锐。你不必全部回答——每次会话回答一两个，长期积累的效果就很显著。

我的好奇心触发点是什么？我的 Pod 最想了解我的哪些方面？

跨 Pod 好奇心：

如果你有多个 Pod——个人、编码、工作流、设备——可以在一次聊天会话中检查所有 Pod 的好奇心。这是聊天界面所能实现的最强大功能之一，而任何单个 Agent 都无法独自做到这一点。

获取我的 Pod 摘要：heidi、heidi-coding 和 heidi-workflow。然后告诉我这三个 Pod 中最重要的好奇心触发点——哪些事情最不确定或尚未解决？

比较我的个人 Pod（heidi）和编码 Pod（heidi-coding）。有没有一方知道、而分享给另一方会有帮助的信息？

更新你的 Pod

如果 Pod 已经加载，Claude 往往会在对话过程中自然而然地更新它——你不必每次都提出要求。但别完全依赖这一点。结束前快速提示一下，可以确保不会遗漏任何内容。

结束会话：

结束之前，请将这次会话中新了解到的关于我的信息更新到我的 Pod 中。

保存特定信息：

请在我的 Pod 中保存以下信息：我正在带领一支由 5 名工程师组成的团队，我们主要使用 Go。

更正错误信息：

我的 Pod 说我喜欢简洁的回答——这已经不对了。我现在想要带有示例的详细解释。请更新这一点。

不要跳过结束总结。 会话中了解到的上下文只有在明确保存后才会保留下来。结束会话时提示一下只需 5 秒。跳过这一步，聊天关闭时这次会话中的学习成果就会消失。

通过聊天调整任何 Agent

聊天不只是用于个人上下文——它还是调整你运行的每个 Agent 的纠正层。它们会自主构建。你可以用日常语言介入并修正偏离的内容。

分类	调整内容	示例提示词
编码	错误的架构约束、过时的技术栈、被否决的方法	“我的编码 Pod 认为我们使用 gRPC——但我们 6 个月前就弃用了。请更正。”
工作流	过时的审批链、已弃用的集成、已更改的政策	“Stripe 备份已弃用。请从工作流 Pod 中移除它。”
多 Agent	Agent 之间的分歧、交接漏洞、相互冲突的世界模型	“我的研究 Agent 和修复 Agent 对 JWT 方案意见不一。请把两种方案都展示给我，并帮我解决分歧。”
设备	无法解释的异常、传感器偏移、意图和优先级设置	“15 日的温度峰值是一次计划中的热测试。请在设备 Pod 中标记原因。”

常见问题

为什么 Claude 不会自动加载我的 pod？

Claude 可以使用 MCP 工具，但如果你不提出请求，它就不知道该调用哪个工具。会话开始时自动加载 pod 已列入计划。目前，你只需说“拉取 [name] 的 pod 摘要”即可触发——只需 2 秒，很快就会成为习惯。

为什么使用摘要，而不是完整加载？

get_pod_summary 速度快，而且会加载 Claude 用于校准所需的信号。完整 pod 包含所有内容——低确定性信号、原始元数据以及整个图谱。普通会话中，你很少需要这些全部内容。默认使用摘要；审计时再完整加载。

免费版 Claude.ai 套餐可以使用吗？

可以。所有 Claude.ai 套餐均支持 MCP 集成。

我可以将同一个 pod 用于 Gemini 或 Cursor 吗？

可以。Event Pod 与模型无关。任何兼容 MCP 的客户端都可以连接到同一个 pod。你的上下文会跟随你，而不会被锁定在 Claude 上。

这与 Claude 内置的记忆有什么不同？

Claude 的记忆会存储对话片段。Event Pod 会构建一个结构化模型，其中包含确定性评分、语义关联和由好奇心驱动的学习，并且适用于你使用的所有工具和模型。它不只是存储，而是一个会随时间不断完善的模型。

---

Agent 世界模型

Agent 是自身大脑的主要构建者。你是编辑。本节介绍核心概念以及使用 Event Pod 的两种方式——由 Agent 自主构建上下文的自主模式，以及由你精确定义要保存内容的受控模式。

自主模式： Agent 自主构建自己的大脑。只需一条系统提示词。由 Agent 决定观察、保存和关联哪些内容。需要时，人工通过聊天进行校准。

受控模式： 由你定义要保存的内容。通过显式工具调用来操作。精确指定事件、关系和资源。需要精确控制而非自动化时使用。

概览

每次 Agent 会话开始时，除非你提供持久化上下文，否则一切都会从零开始。Event Pod 是持久化层——一个记录 Agent 所学内容的结构化模型，并通过确定性评分反映 Agent 对每个信号的确信程度。

Event Pod 是一个 MCP 服务，Agent 通过 HTTP 连接。Agent 调用工具——save_event、apply_learning、get_pod_summary——由 Event Pod 负责持久化。pod 存储在服务端，而非 Agent 的上下文窗口中，因此能够在不同会话、模型和工具之间保留。每个 pod 可同时连接两方：Agent（通过工具调用）和人工（通过聊天）。任何兼容 MCP 的客户端都可以使用——Claude、Gemini、Cursor、自定义 Agent 都能连接到同一个 pod。

核心要点：你不需要替 Agent 编写它的大脑。 只要系统提示词合适，Agent 就会自行观察相关内容、保存内容并构建知识图谱。人工的职责是校准——审查 Agent 学到的内容、纠正偏差，并补充 Agent 无法观察到的上下文。

一个 Agent，多个通道。 通道描述的是你要构建的 上下文类型，而非彼此独立的系统。实际的编码 Agent 会从编码通道获取代码库知识，从工作流通道获取部署模式，并从聊天通道获取用户偏好——所有信号都在同一个 pod 中，并且都可以通过 get_relevant_context 一并检索。可自由组合。

两种模式

	自主模式	受控模式
设置	添加系统提示词片段——完成	将显式工具调用接入生命周期钩子
由谁决定保存什么	Agent	你
适用场景	大多数用例——让它自然学习	需要指定事件、关系或精确控制时
人工职责	通过聊天校准——审查、纠正、扩展	设计架构并通过聊天校准
是否需要代码	不需要——只需系统提示词	需要——Python/JS/curl

大多数 Agent 会先采用自主模式，成熟后再为特定高价值信号添加受控保存。你不必二选一——两种模式可以组合使用。

自主模式

将以下内容放入系统提示词。Agent 会处理其余工作——在会话开始时加载上下文，在会话期间观察信号，呈现好奇触发点，并在结束时持久化学到的内容。

## Event Pod -- Context Instructions

You have access to Event Pod tools for persistent context.
User ID: {USER_ID}

SESSION START:
Call get_pod_summary before responding to any task.
If the user describes their task, also call get_relevant_context
with that task as the query.

DURING THE SESSION:
- When the user corrects you: immediately call record_observation
  then apply_learning on the relevant event.
- When you observe expertise, preferences, or patterns worth
  remembering: note them for saving at session end.
- Once per session at a natural pause: call get_curiosity_triggers
  with max_triggers=2. Weave one probe naturally into conversation --
  don't list them as questions.

SESSION END -- before the conversation closes:
1. Call save_event for each new signal observed this session.
   Start all certainty values at 0.3.
2. Call update_session with interactions=1.
   Call this exactly once -- never mid-session.

IMPORTANT:
- You decide what's worth saving. Not every mention -- sustained
  patterns, explicit corrections, and clear preferences only.
- The human can audit and correct anything via chat at any time.

大多数使用场景只需这些。Agent 会从会话中构建自己的模型。人类通过聊天进行校准。随着时间推移，Pod 会不断积累，无需编写任何额外代码。

受控模式

如果你想定义特定事件、明确建立信号之间的关系，或将资源附加到上下文，请使用受控保存。受控模式和自主模式可以组合使用——在系统提示词的基础上，为你特别关注的信号添加显式保存。

保存特定事件：

await call_pod("save_event", {
    "user_id": "heidi",
    "key": "python",
    "signal_type": "competence",
    "value": 0.85,
    "certainty": 0.3,       # always start low
    "gloss": "Strong Python -- corrects examples, uses advanced patterns",
    "validation_type": "logic",
    "meta": { "observed_via": "code_review" }
})

在语义上关联两个事件：

await call_pod("link_events", {
    "user_id": "heidi",
    "source_key": "python",
    "source_signal_type": "competence",
    "target_key": "data-science",
    "target_signal_type": "competence",
    "relationship": "ENABLES",
    "note": "Python expertise enables data science work"
})

将资源附加到事件：

await call_pod("link_resource", {
    "user_id": "heidi",
    "key": "python",
    "signal_type": "competence",
    "resource_type": "project",
    "resource": {
        "name": "acme/backend",
        "project_id": "acme/backend",
        "note": "Primary Python codebase"
    }
})

生命周期钩子（受控模式）

如果你要编写显式代码，而不是依赖系统提示词，这四个函数就能覆盖完整生命周期。每个函数都是可直接使用的 Python 代码——将 call_pod 替换为 MCP 客户端调用工具的方法。

初始化——会话开始

async def agent_init(user_id: str, task: str = None):
    summary = await call_pod("get_pod_summary", {
        "user_id": user_id,
        "include_glosses": True,
        "include_freshness": True
    })
    context = None
    if task:
        context = await call_pod("get_relevant_context", {
            "user_id": user_id,
            "query": task,
            "max_results": 10,
            "include_resources": True
        })
    return summary, context

观察——会话期间的信号

async def agent_observe(user_id, session_id, key, signal_type,
                        observation_type, direction, raw_content, error_magnitude):
    # Always: record first, then apply
    await call_pod("record_observation", {
        "user_id": user_id, "session_id": session_id,
        "key": key, "event_signal_type": signal_type,
        "signal_type": observation_type,
        "signal_data": { "direction": direction, "raw_content": raw_content }
    })
    await call_pod("apply_learning", {
        "user_id": user_id, "key": key, "signal_type": signal_type,
        "error_direction": direction, "error_magnitude": error_magnitude
    })

错误幅度参考：

发生的情况	幅度	方向
独立佐证	0.05--0.1	增加
同一来源重复	0.02--0.05	增加
具体性提升	0.1--0.15	增加
时间上的确认	~0.1	增加
用户提出矛盾或纠正	0.2--0.4	减少

好奇探查——定期探测

async def agent_curiosity(user_id: str, max_triggers: int = 3):
    return await call_pod("get_curiosity_triggers", {
        "user_id": user_id,
        "max_triggers": max_triggers,
        "include_probes": True
    })
    # Use triggers[n].suggested_probes as conversation starters
    # Rephrase naturally -- never read them verbatim

关闭——会话结束

async def agent_shutdown(user_id: str, new_events: list):
    for event in new_events:
        await call_pod("save_event", {
            "user_id": user_id,
            "key": event["key"],
            "signal_type": event["signal_type"],
            "value": event["value"],
            "certainty": event.get("certainty", 0.3),
            "gloss": event.get("gloss", ""),
            "meta": event.get("meta", {})
        })
    # Exactly once -- never mid-session
    await call_pod("update_session", {
        "user_id": user_id, "interactions": 1
    })

信号类型

类型	跟踪内容	示例键
能力	技能或知识水平	python、distributed-systems
偏好	沟通或工作风格	verbosity、code-before-explanation
主张	跟踪的命题或信念	microservices-preferred
实体	命名的人、组织或工具	tool-terraform、company-acme
事件	事故、里程碑、决策	auth-refactor-completed
指标	可测量的量	api-latency-p99
模式	重复出现的行为或趋势	prefers-examples-over-theory
状态	当前状态或阶段	project-alpha-status

确信度与学习

每个事件都有一个介于 0 和 1 之间的 certainty 分数。系统在无把握时灵活，在有把握时稳定——学习率会自动调整。你设定方向和幅度；系统负责处理学习率。

范围	含义	行为
0.0 -- 0.3	低——新出现或支持较弱	更新快，乐于修正
0.3 -- 0.6	中——信心逐渐建立	以适中速率更新
0.6 -- 0.8	高——有充分支持	抵御噪声
0.8 -- 1.0	很高——已确立	只有遇到强烈矛盾时才会改变

**新事件始终从 0.3 开始。**不要手动设定较高的确信度——让佐证逐步累积。

人类校准

Agent 会构建它能够观察到的内容。人类则补充它无法观察到的内容——组织背景、意图、会话之外作出的决策。聊天界面是两种模式的校准层。人类无需编写代码。

**设计你的 Agent，让它主动邀请校准。**将好奇触发点自然地融入对话。在会话结束时展示已保存的内容。定期提供 Mermaid 图表，让人类直观地发现校准偏差。人类纠正得越快，确信度就越快趋近事实。

---

编码与代码仓库上下文

你的编码 Agent 会自主梳理技术栈、团队约定、故障模式和架构决策。它不会再建议你已经排除过的方案。它知道约束存在的原因，也会将故障与导致故障的架构决策关联起来。

自主模式： Agent 会构建代码库地图，从每次会话中观察技术栈、约定、故障和约束。无需预先定义架构。

受控模式： 由你定义高价值信号，包括明确的代码仓库上下文、关联的故障模式和附加的文档及 ADR。适用于对准确性要求较高的场景。

概述

没有持久上下文的编码 Agent 每次会话都会重新发现同样的事情——询问技术栈，忽略会排除一整类方案的约束，还会提出团队在六个月前尝试后放弃的方法。Event Pod 通过让 Agent 随时间积累代码库模型来解决这个问题。

Agent 是主要的编写者。它会从实际会话中观察重要信息，而不是依赖你预先定义的合成架构。人类开发者通过聊天参与其中，补充 Agent 无法观察到的组织背景：在 Slack 中做出的决策、合同中的约束，以及某个库被禁用的原因。

自主模式——编码系统提示词

将以下内容添加到编码 Agent 的系统提示词中——适用于 Claude Code、Cursor、Cline 或任何兼容 MCP 的 IDE Agent。Agent 会根据会话自行构建代码库模型。如果模型发生偏差，你可以通过聊天对其进行校准。

## Event Pod -- Coding Context

You have access to Event Pod tools. User ID: {USER_ID}

SESSION START:
1. Call get_pod_summary for this user.
2. Call get_repo_context for repo: {REPO_NAME}.
3. If a specific task is described, call get_relevant_context
   with that task as the query.

DURING THE SESSION -- observe and save:
- Stack, languages, frameworks encountered -> competence events
- Architectural rules and constraints -> claim events
- Approaches that failed or were rejected -> event signals
  (always include WHY in the gloss and a revisit_when in meta)
- Recurring failure patterns -> pattern events
- Team conventions and process rules -> preference events
- Current work in progress -> state events

When the user corrects your understanding of the codebase:
immediately call record_observation then apply_learning.

SESSION END:
1. Save all new signals observed (save_event for each).
2. Update repo context if stack or constraints changed
   (save_repo_context).
3. Call update_session with interactions=1 -- exactly once.

Agent 会自行决定哪些内容值得保存。它不会保存每次提及的内容，只保存持续出现的模式、明确的约束和已确认的故障。这是有意为之。与不完整的 Pod 相比，嘈杂的 Pod 更难校准。

受控模式

当你想明确指定 Agent 所掌握的信息时，可使用受控保存——例如，为新的 Agent 初始化信息、记录会话中未做出的决策，或在信号间建立精确关联。它可以与自主模式结合使用。

代码仓库上下文

save_repo_context 会持久保存代码库元数据，在同一代码仓库的所有会话中保留。这是关于代码本身的共享知识，与用户级信号相互独立。

明确初始化代码仓库上下文：

await call_pod("save_repo_context", {
    "user_id": user_id,
    "repo_name": "acme/backend",
    "metadata": {
        "stack": ["Go 1.22", "PostgreSQL 15", "Redis", "Temporal"],
        "architecture": "Modular monolith, domain-driven",
        "constraints": [
            "No ORM -- raw SQL only",
            "No global state",
            "All DB calls use context cancellation"
        ],
        "test_strategy": "Table-driven unit tests, integration tests in /testdata",
        "deploy": "GitHub Actions -> staging -> manual prod promotion",
        "conventions": [
            "Conventional commits",
            "PR review required before merge",
            "No force-push to main"
        ]
    }
})

在会话开始时加载：

repo = await call_pod("get_repo_context", {
    "user_id": user_id,
    "repo_name": "acme/backend"
})

故障记忆

被否决的方法是编码 Agent 最值得记住的内容，也是无状态 Agent 下次会话最先再次提出的内容。保存时应提供足够的上下文，以便数月后仍然有用。

await call_pod("save_event", {
    "user_id": user_id,
    "key": "grpc-streaming-rejected",
    "signal_type": "event",
    "value": 1.0,
    "certainty": 0.9,
    "gloss": "Tried gRPC streaming for real-time updates. Reverted: complexity too high for current team size. REST + polling is sufficient at current scale.",
    "meta": {
        "decided_by": "team",
        "date": "2025-11",
        "revisit_when": "team > 10 engineers OR > 10k concurrent users"
    }
})

务必包含 revisit_when。 这会将“我们试过了”变成“我们试过了——以下情况出现时值得再试一次”。随着条件变化，Agent 可以主动提示这些信息。

将故障与约束关联

受控模式的真正优势在于能够以语义方式关联信号：导致某项约束的故障模式，以及促成某项决策的约束。这些关联让 Agent 能够解释规则存在的原因，而不只是说明规则内容。

将故障模式关联到由此产生的约束：

# Save the failure pattern
await call_pod("save_event", {
    "user_id": user_id,
    "key": "connection-pool-exhaustion",
    "signal_type": "pattern",
    "value": 0.9,
    "certainty": 0.85,
    "gloss": "Pool exhaustion under load -- seen 3x in prod. Always traced to unbounded concurrent queries."
})

# Save the architectural constraint it produced
await call_pod("save_event", {
    "user_id": user_id,
    "key": "max-db-connections-constraint",
    "signal_type": "claim",
    "value": 1.0,
    "certainty": 0.95,
    "gloss": "Hard cap: 20 DB connections per service instance. Non-negotiable.",
    "meta": { "set_by": "ops", "date": "2025-08" }
})

# Link them -- failure ENABLES constraint (caused it to exist)
await call_pod("link_events", {
    "user_id": user_id,
    "source_key": "connection-pool-exhaustion",
    "source_signal_type": "pattern",
    "target_key": "max-db-connections-constraint",
    "target_signal_type": "claim",
    "relationship": "ENABLES",
    "note": "Pool exhaustion incidents caused this constraint to be imposed"
})

将 ADR 或设计文档附加到约束：

await call_pod("link_resource", {
    "user_id": user_id,
    "key": "max-db-connections-constraint",
    "signal_type": "claim",
    "resource_type": "url",
    "resource": {
        "name": "ADR-012: DB connection limits",
        "url": "https://github.com/acme/backend/blob/main/docs/adr/012-db-connections.md",
        "note": "Full decision record with context and alternatives considered"
    }
})

关联的资源会自动显示。 当 Agent 对任何与数据库连接有关的内容调用 get_relevant_context 时，ADR 链接也会一并提供。即使没人告知 Agent 该决策记录的存在，它也能引用该记录。

人类对齐——编码

Agent 可以观察代码，但工程师掌握着组织知识。在 Slack 中做出的决策、两个季度前在白板讨论中被否决的方案、某个库被禁止用于代码库的原因——这些都无法仅从会话中观察到。开发者通过聊天将其补充进来。

添加 Agent 无法看到的上下文：

请将我们去年决定不采用 GraphQL 的事保存到我的编码 pod 中——团队认为，以我们的规模，N+1 问题带来的代价不值得换取灵活性。将这条信息添加到 acme/backend 仓库的上下文中。

审查代码库地图：

我的 pod 了解多少 acme/backend 的架构？请展示它正在跟踪的约束。

查看知识图谱：

请展示一张以 DB 连接约束为中心的编码 pod 示意图。有哪些内容与它相连？

纠正偏差：

我的 pod 说我们使用常规提交，但六个月前我们又改回了自由格式的提交消息。请更新这条信息。

---

任务与工作流自动化

了解其运行环境的工作流 Agent 能够处理无状态 Agent 无法触及的任务。哪些工具连接到哪些服务、哪些地方容易出问题、需要哪些审批。Agent 从运行中构建这个模型；人类则补充只有他们才能提供的组织背景信息。

自主模式： Agent 绘制环境地图。从每次运行中学习集成、故障模式和规律。运行模型会自行构建。

受控模式： 由你预先设定约束，包括审批链、权限和服务地图。适用于重视精准性和可审计性的场景。

概览

工作流 Agent 会因上下文丢失而浪费时间——重新发现哪些集成可用、上次出了什么问题、哪些步骤需要审批。Event Pod 为工作流 Agent 提供一个持续积累而非重置的运行模型。Agent 从运行中构建模型；操作人员则预先设定需要从第一天起就强制执行的约束。

自主模式——工作流系统提示词

## Event Pod -- Workflow Context

You have access to Event Pod tools. User ID: {USER_ID}

SESSION START:
1. Call get_pod_summary for this user.
2. Call get_service_context to check integration status.
3. Call get_agent_context for agent_id: {AGENT_ID},
   context_type: task_history to review recent runs.

DURING RUNS -- observe and save:
- New tool or service integrations -> entity events
  (include auth type, permissions, and any write restrictions)
- Approval requirements discovered -> claim events
  (include threshold, approver, and SLA in meta)
- Recurring failures or edge cases -> pattern events
  (include workaround and first-seen in meta)
- Current service health issues -> save_service_context

AFTER EACH RUN:
1. Call save_agent_context with context_type: task_history.
   Include what completed, what failed, and why.
2. Save any new patterns or constraints discovered.
3. Call update_session with interactions=1 -- exactly once.

审批链是最重要的事项。 如果 Agent 在运行过程中发现了审批要求，就应立即保存——不要等到关闭时再保存。下一次运行就会从一开始遵守这项要求。

受控模式

在首次运行前使用受控保存来预先设定运行模型，让 Agent 一开始就了解已知约束，而不必费力摸索。

工具集成

明确预先设定集成地图：

await call_pod("save_event", {
    "user_id": user_id,
    "key": "salesforce-crm",
    "signal_type": "entity",
    "value": 1.0,
    "certainty": 0.95,
    "gloss": "Salesforce connected via OAuth. Agent is read-only. All writes require human approval.",
    "meta": {
        "auth_type": "oauth",
        "agent_permissions": "read",
        "write_approval_required": True,
        "approver": "ops-lead",
        "approval_sla_hours": 4
    }
})

审批链

审批要求属于声明——是 Agent 必须遵守的绝对规则。请明确预先设定这些要求，这样 Agent 就不必通过违反规则来发现它们。

预先设定审批规则：

await call_pod("save_event", {
    "user_id": user_id,
    "key": "payment-approval-required",
    "signal_type": "claim",
    "value": 1.0,
    "certainty": 0.99,  # high -- this is a hard rule
    "gloss": "Any payment over $500 requires finance approval. Under $500 is autonomous.",
    "meta": {
        "threshold_usd": 500,
        "approver": "[email protected]",
        "sla_hours": 4,
        "escalation": "[email protected] if no response in 4h"
    }
})

将审批链关联到集成：

await call_pod("link_events", {
    "user_id": user_id,
    "source_key": "payment-approval-required",
    "source_signal_type": "claim",
    "target_key": "salesforce-crm",
    "target_signal_type": "entity",
    "relationship": "PART_OF",
    "note": "Payment approval rule governs all Salesforce write operations"
})

服务上下文

跟踪工作流所依赖服务的健康状态。Agent 会在会话开始时检查状态，并可在依赖项降级时跳过步骤或改用其他路径。

await call_pod("save_service_context", {
    "user_id": user_id,
    "service_name": "payment-gateway",
    "status_data": {
        "status": "degraded",
        "last_checked": "2025-11-15T14:32:00Z",
        "known_issues": ["High latency on EU endpoints"],
        "fallback": "stripe-backup"
    }
})

任务历史

保存每次运行执行了什么、做出了什么决定以及遇到了什么情况。下一次运行可以完整了解之前发生的事，包括失败情况及其背后的原因。

await call_pod("save_agent_context", {
    "user_id": user_id,
    "agent_id": "invoice-workflow",
    "context_type": "task_history",
    "data": {
        "task": "Process November invoices",
        "completed": 47,
        "failed": 3,
        "failure_reason": "Vendor ID mismatch on EU invoices (legacy pre-2023 format)",
        "flagged_for_review": ["INV-2041", "INV-2089"],
        "duration_minutes": 12
    }
})

故障模式

如果某次运行反复以相同方式失败，请将其保存为一种模式。Agent 会学会提前预判——检查前置条件、选择备用方案，或在问题蔓延前将其告知人类。

await call_pod("save_event", {
    "user_id": user_id,
    "key": "eu-invoice-vendor-mismatch",
    "signal_type": "pattern",
    "value": 0.8,
    "certainty": 0.75,
    "gloss": "EU invoices with pre-2023 vendor ID format fail matching. Route to manual review.",
    "meta": {
        "first_seen": "2025-09",
        "frequency": "~5% of EU invoices",
        "workaround": "manual-review queue",
        "fix_status": "backlog -- vendor migration Q1 2026"
    }
})

人类对齐——工作流

运营背景存在于人们的脑海中——六个月前的审批链、通过惨痛经验了解到的供应商习惯、合同中的集成限制。Agent 会构建它所遇到的内容。运营人员补充它无法观察到的信息。

添加未记录的约束：

请将法律团队必须在任何集成上线前审核所有新供应商合同这一要求保存到我的工作流 Pod 中。这没有任何书面记录，但一直都是必需的。

更新过时状态：

Stripe 备用集成上个月已弃用。请将其从服务上下文中移除，并更新支付回退方案。

审查 Agent 所掌握的信息：

我的工作流 Pod 了解哪些发票流程信息？它正在跟踪哪些故障模式？请展示审批链约束。

---

多 Agent 与跨 Pod

多个 Agent 各自构建自己的世界模型。Pod 让它们无需由一个中央协调器统筹一切也能协作——而聊天是人类介入、解决 Agent 无法达成一致之处的方式。

Agent 的工作： 独立构建。每个 Agent 都会积累自己的模型。交接会延续上下文。分歧会自然显现。

人类的工作： 解决分歧。当 Agent 意见不一时，由人类通过聊天做出决定。解决结果会广播给所有 Agent。所有人都能受益。

概览

在多 Agent 系统中，上下文丢失发生在交接时。Agent A 进行深入研究；Agent B 从零开始，完全不了解研究内容。新 Agent 在项目进行三周后加入，不得不从头接受简报。Event Pod 同时解决这两个问题：Agent 向 Pod 写入内容、从 Pod 读取内容，而新 Agent 可以从先前 Agent 已解决的知识中获得初始化。

三种协调模式涵盖了大多数情况：

• 交接——一个 Agent 为下一个 Agent 留下结构化上下文
• 比较——展示两个 Agent 的模型在哪些方面存在分歧；由人类解决
• 初始化新 Agent——使用现有 Agent 已解决的上下文为新 Agent 初始化

自主模式——多 Agent 系统提示词

每个 Agent 都使用带有独立 agent_id 的系统提示词运行。Agent 独立构建、留下交接信息，并保持命名空间隔离，以便始终追溯每个 Agent 的贡献。

## Event Pod -- Multi-Agent Context

You have access to Event Pod tools.
User ID: {USER_ID}
Your agent ID: {AGENT_ID}

SESSION START:
1. Call get_pod_summary for this user.
2. Call get_agent_context for your agent_id to load your
   own task history.
3. Check for handoffs from other agents:
   call get_agent_context for any upstream agent_ids
   with context_type: task_history.

DURING THE SESSION:
- Save what you learn as events on the shared pod.
- When you make a significant decision, call save_agent_context
  with context_type: decision so other agents can trace it.
- If you encounter something that contradicts another agent's
  saved context, note it -- don't silently overwrite it.
  Flag it for human review.

SESSION END:
1. Save a handoff via save_agent_context, context_type: task_history.
   Include: what you did, what you found, what you'd recommend next,
   and what you're handing off to.
2. Save any new events observed.
3. Call update_session with interactions=1 -- exactly once.

受控模式

在交接、比较和初始化等最需要精确性的场景中，使用受控保存。

Agent 交接

一个 Agent 完成某个阶段并由另一个 Agent 接手时，交接内容会以结构化形式保存。下一个 Agent 在开始前读取这些内容——无需重新简报，也不会丢失上下文。

Agent A——保存交接信息：

await call_pod("save_agent_context", {
    "user_id": user_id,
    "agent_id": "research-agent",
    "context_type": "task_history",
    "data": {
        "task": "Security audit -- auth module",
        "status": "complete",
        "findings": [
            "JWT secret hardcoded in config.go:42",
            "No rate limiting on /login",
            "Session tokens don't expire"
        ],
        "severity_order": ["JWT secret", "session expiry", "rate limiting"],
        "files_examined": ["auth/", "middleware/auth.go"],
        "handed_off_to": "fix-agent",
        "recommended_first": "JWT secret -- highest severity, easiest fix"
    }
})

Agent B——在会话开始时读取交接信息：

handoff = await call_pod("get_agent_context", {
    "user_id": user_id,
    "agent_id": "research-agent",  # read from the agent that handed off
    "context_type": "task_history"
})

比较与分歧

当两个 Agent 分别为同一环境构建模型时，compare_pods 会找出它们一致之处、存在分歧之处，以及各自掌握而对方不具备的信息。分歧是信号——它们标记着等待人类做出决定的事项。

comparison = await call_pod("compare_pods", {
    "pod_a": "research-agent-pod",
    "pod_b": "fix-agent-pod",
    "signal_type": "claim"  # focus on architectural claims
})

# comparison.agreements   -- shared keys, similar values (agents agree)
# comparison.divergences  -- shared keys, different values (needs resolution)
# comparison.gaps         -- keys unique to each pod (knowledge gaps)

分歧不是错误。 当两个 Agent 意见不一时，这意味着有待人类做出决定。在 UI 中展示分歧，让用户通过聊天解决，然后广播解决结果。所有 Agent 都能从人类的一次决定中受益。

广播解决结果

当人类通过聊天解决分歧时，将最终采纳的上下文广播给所有受影响的 Agent。每个 Agent 都能获得修正后的模型——无需任何 Agent 再次自行发现。

agent_pods = ["research-agent-pod", "fix-agent-pod", "review-agent-pod"]

for pod_id in agent_pods:
    await call_pod("save_event", {
        "user_id": pod_id,
        "key": "connection-pooling-policy",
        "signal_type": "claim",
        "value": 1.0,
        "certainty": 0.95,  # high -- human confirmed
        "gloss": "Use connection pooling in all new services. Human-confirmed 2025-11.",
        "meta": {
            "resolved_by": "human",
            "date": "2025-11-15",
            "supersedes": "prior divergence between research and fix agents"
        }
    })

初始化新 Agent

新 Agent 加入现有项目时，通常会从零开始——数周的上下文就此丢失。可以改为使用先前 Agent 已解决的知识为它初始化。它从一开始就能高效工作。

# 1. Create the new pod
await call_pod("create_pod", {
    "user_id": "devops-agent-pod",
    "name": "DevOps Agent",
    "pod_type": "intelligence"
})

# 2. Load resolved context from existing agents
research_history = await call_pod("get_agent_context", {
    "user_id": "research-agent-pod",
    "context_type": "task_history"
})
decisions = await call_pod("get_agent_context", {
    "user_id": "fix-agent-pod",
    "context_type": "decision"
})

# 3. Seed the new pod with resolved knowledge
for decision in decisions["decisions"]:
    await call_pod("save_event", {
        "user_id": "devops-agent-pod",
        "key": decision["key"],
        "signal_type": "claim",
        "value": decision["value"],
        "certainty": 0.7,  # inherit with moderate certainty -- let it validate
        "gloss": f"Inherited from prior agents: {decision['gloss']}"
    })

以适中的置信度继承。 将继承知识的置信度设为约 0.7，而不是 0.95。新 Agent 应验证收到的信息，而不是将继承的上下文视为绝对事实。让它通过自己的观察逐步建立高置信度。

人类对齐 —— 多 Agent

在多 Agent 系统中，观点分歧不可避免。Agent 的训练方式不同，观察到的环境部分不同，运行的模型也不同——因此它们会构建出不同的世界模型。人类的职责是仲裁。聊天是处理这一切的界面。

在一个会话中调取跨 Agent 上下文：

调取我的三个 Agent pod 的摘要：research-agent-pod、fix-agent-pod 和 devops-agent-pod。它们各自对部署策略了解多少？它们有哪些分歧？

解决分歧：

research Agent 和 fix Agent 对是否使用连接池意见不一。research Agent 是对的。请用已确认的决定更新全部三个 pod，并注明这是由人类裁定的。

审查 Agent 的决策记录：

给我看看 fix Agent 做出并保存的所有决策。我想先审查它的推理过程，再将工作移交给 DevOps Agent。

检查所有 Agent 的好奇点：

三个 Agent pod 中最常见的好奇触发因素是什么？系统整体还有哪些未知之处？

一个人的决定，让所有 Agent 都受益。 在聊天中解决分歧时，请将决定广播出去。你在一次对话中提供的机构知识，会传播给所有需要它的 Agent。这就是对齐循环的复利效应。

---

设备与生态系统

嵌入硬件中的 Agent 不只是执行任务——它还会建立对物理环境的因果模型。传感器是信号。状态不断累积。模式逐渐显现。人类可以随时用通俗语言审查、纠正并扩展设备学到的知识。

**设备 Agent 的职责：**了解其环境。自主地将传感器读数作为信号摄取、建立状态模型、检测模式并发现异常。

**人类的职责：**提供上下文和意图。解释某个读数为何异常、状态变化意味着什么，以及设备应优先处理什么。随时都能通过聊天沟通。

这一方向着眼于未来。 核心工具目前已可使用。完整的设备端部署愿景——让 Agent 在嵌入式硬件上本地运行，并让 pod 与边缘端同步——仍在积极开发中。请在构建时考虑这一点。

概览

传统的 IoT 架构会将数据推送到云端，再将决策拉回设备。拥有持久世界模型的 Agent 改变了这一点：智能驻留在设备上，模型在本地不断累积，人类则可以用自然语言与之交互，而无需查询仪表板或编写 SQL。

每次传感器读数都可能成为信号。每次状态变化都是事件。每种反复出现的行为都是一种模式。Event Pod 为设备 Agent 提供脚手架，使其能够随时间积累这些知识，并随着信心不断增强而据此采取行动。

设备模型

设备 pod 对设备运行的物理环境进行建模——不只是设备测量了什么，还包括这些测量值意味着什么。

内容	信号类型	示例
传感器基线	metric	环境温度正常范围：18--24 C
当前设备状态	state	HVAC：制冷 / 空闲 / 故障
反复出现的行为	pattern	每个工作日早上 9am，温度都会升高 2 C
环境相关断言	claim	西侧窗户打开时，B 室空气质量会下降
事件与异常	event	2025-11-03 出现功率峰值，原因：未知
已连接设备	entity	Sensor-node-4、gateway-main、thermostat-A

将传感器视为信号

每次传感器读数都可以保存为 metric 事件。随着时间推移，pod 会为每个传感器建立统计基线——偏离基线本身也会成为有意义的信号。

await call_tool("save_event", {
    "user_id": "device-pod-floor2",
    "key": "ambient-temperature",
    "signal_type": "metric",
    "value": 0.74,  # normalized: 0=min, 1=max of expected range
    "certainty": 0.9,  # sensor is reliable
    "gloss": "22.1 C -- within normal range",
    "validation_type": "direct",  # sensor is ground truth
    "meta": {
        "raw_value": 22.1,
        "unit": "celsius",
        "sensor_id": "temp-sensor-4",
        "timestamp": "2025-11-15T09:00:00Z"
    }
})

将传感器值归一化到 0--1。 将传感器的预期范围映射到 [0, 1]。通常读数为 18--24 C 的温度传感器，可将 22 C 映射为约 0.67。这样一来，pod 就能用统一的尺度比较不同传感器类型的信号。

状态与模式

当前状态：

使用 state 事件跟踪设备或系统当前所处的模式或状态。随着状态转换的发生更新这些事件，pod 会随着时间推移累积状态变化历史。

await call_tool("save_event", {
    "user_id": "device-pod-floor2",
    "key": "hvac-state",
    "signal_type": "state",
    "value": 0.8,  # 0=off, 0.5=idle, 1=active/fault
    "certainty": 0.95,
    "gloss": "HVAC: cooling mode, running normally",
    "meta": { "mode": "cooling", "set_point": 21 }
})

模式：

当 Agent 检测到重复行为，并且已通过多次观察确认时，将其保存为 pattern 事件。模式让 Agent 能够提前预测并采取行动。

await call_tool("save_event", {
    "user_id": "device-pod-floor2",
    "key": "morning-temp-spike",
    "signal_type": "pattern",
    "value": 0.75,  # strength of pattern
    "certainty": 0.65,  # still building confidence
    "gloss": "Temperature rises ~2 C on weekday mornings around 9am. Likely occupancy-driven.",
    "meta": {
        "observed_n": 12,
        "hypothesis": "office occupancy",
        "suggested_action": "Pre-cool to 20 C by 8:45am on weekdays"
    }
})

异常检测

当传感器读数显著偏离既定基线时，将其保存为确定性较低的 event（原因未知），并通过好奇心触发器标记，供人工审核。

# Sensor read 31 C -- well outside normal 18--24 C range
await call_tool("save_event", {
    "user_id": "device-pod-floor2",
    "key": "temp-anomaly-2025-11-15",
    "signal_type": "event",
    "value": 1.0,
    "certainty": 0.2,  # cause uncertain -- needs human input
    "gloss": "Temperature spike to 31 C at 14:22 UTC. No known cause. HVAC was in cooling mode.",
    "meta": {
        "raw_value": 31.0,
        "expected_range": [18, 24],
        "hvac_state": "cooling",
        "flagged_for_review": True
    }
})

人工对齐——设备

设备观察物理现实，但人类能提供意图、上下文和因果关系，这些都不是传感器所能提供的。窗户为什么一直开着？这次峰值是测试还是故障？当设备需要进行取舍时，应该优先考虑什么？

解释异常：

15 日的温度峰值，是我们在 B 室进行热测试时造成的。请更新 pod，注明原因并将其标记为预期情况。

添加环境上下文：

请在 2 楼的 pod 中保存以下信息：西向传感器在午后阳光照射下的读数总是偏高 1--2 C。这是结构性现象，不是异常。

设置设备意图：

我希望 2 楼的 Agent 在工作日早上 8 点至下午 6 点之间优先考虑空气质量，而非温度舒适度。请将其保存为偏好。

生态系统上下文

设备并非孤立运行。使用 link_events 关联设备生态系统中的相关信号，例如将温度异常与电力峰值关联，或将状态变化与已知模式关联。

await call_tool("link_events", {
    "user_id": "device-pod-floor2",
    "source_key": "temp-anomaly-2025-11-15",
    "source_signal_type": "event",
    "target_key": "power-spike-2025-11-15",
    "target_signal_type": "event",
    "relationship": "RELATED_TO",
    "note": "Both anomalies occurred within 2 minutes. Possible causal link."
})

Devices 分区中使用的信号类型

信号	用例
metric	传感器读数、环境测量值
state	设备模式、运行状态、阶段
pattern	重复行为、环境周期
event	异常、事件、状态转换
claim	环境规则、结构限制
entity	传感器、网关、连接的设备
preference	设备优先级、人类设定的意图

---

完整参考

完整的工具索引、信号类型、数据模型和集成参考。所有分区共用。

信号类型

每个事件都有一个 signal_type，用于分类其所代表的知识类型。八种类型涵盖了全部范围。

类型	表示内容	值的含义	分区
competence	某个领域的技能或知识水平	0 = 新手，1 = 专家	Chat、Agent、Coding
preference	沟通或行为设置	0 = 低/关，1 = 高/开	Chat、Agent、Coding、Devices
claim	被跟踪的命题或信念	0 = 假/不接受，1 = 真/接受	Agent、Coding、Workflow、Multi-agent
entity	命名实体——人物、组织、工具、设备	0 = 不活跃，1 = 活跃/相关	所有分区
event	事件、里程碑、决策、异常	0 = 轻微，1 = 重大	Coding、Workflow、Devices
metric	可测量的量	在预期范围内归一化至 0--1	Coding、Workflow、Devices
pattern	重复行为或趋势	0 = 弱，1 = 强模式	Chat、Coding、Workflow、Devices
state	当前状态或运行阶段	取决于上下文（在 gloss 中说明）	Workflow、Multi-agent、Devices

确定性与学习

每个事件都带有一个介于 0 和 1 之间的 certainty 分数，表示模型对其所掌握的有关此信号的信息有多确定。

确定性范围	含义	行为
0.0 -- 0.3	低——新信息或支持较弱	快速更新；乐于修正
0.3 -- 0.6	中——信心逐步建立	以中等速度更新
0.6 -- 0.8	高——有充分依据	抵御噪声；仅在出现强信号时更新
0.8 -- 1.0	非常高——已得到坚实证实	高度稳定；只有重大矛盾才会改变它

将新观察的初始值设为 0.3，并让学习过程随时间不断完善。系统会在无知时保持灵活，在确定时保持稳定——学习速率会根据当前确定性自动调整。

验证类型

类型	适用场景
direct	传感器或数据源提供客观的真实依据（比较预测值与实际值以计算误差）
logic	没有外部传感器——根据相互佐证、矛盾或具体程度来判断误差大小

误差幅度指南（适用于 apply_learning）

信号类型	幅度	方向
独立佐证	0.05 -- 0.1	增加
同一来源重复	0.02 -- 0.05	增加
具体程度提升	0.1 -- 0.15	增加
时间上的确认	~0.1	增加
矛盾	0.2 -- 0.4	减少

读取工具

工具	用途	关键参数
get_pod_summary	简明易读的概览——包含带释义和新鲜度信息的主要信号	user_id、include_glosses、include_freshness
get_pod	完整的 pod 状态，包括所有事件	user_id、include_vectors、include_curiosity
get_events	所有事件，可按 signal_type 筛选	user_id、signal_type、validation_type
get_relevant_context	与任务最相关的事件——按匹配度和确定性评分	user_id、query、max_results
query_pod	针对所有事件的自然语言问题	user_id、query
get_low_certainty	确定性低于阈值的事件——最佳验证候选项	user_id、threshold
get_curiosity_triggers	需要验证、已过时或观察不足的事件	user_id、max_triggers、include_probes
get_gap_analysis	按调查优先级排序的高价值、低确定性信号	user_id、max_gaps
get_convergence_report	自上次报告以来的新事件、确定性变化和过时信号	user_id、since_days

写入工具

工具	用途	关键参数
create_pod	为用户或实体初始化新的 pod	user_id、name、pod_type
save_event	保存或更新任意事件	user_id、key、signal_type、value、certainty、gloss、meta
record_observation	记录原始行为信号（纠正、互动等）	user_id、session_id、signal_type、signal_data
apply_learning	根据观察更新事件的值和确定性	user_id、key、signal_type、error_direction、error_magnitude
update_session	增加会话和互动计数器——在结束时调用一次	user_id、interactions
delete_event	按键移除特定事件	user_id、key、signal_type
delete_pod	永久删除 pod 和所有数据——不可撤销	user_id、confirm: true

图谱工具

工具	用途	关键参数
link_events	在两个事件之间创建语义关系	user_id、source_key、target_key、relationship、note
get_event_cluster	从某个事件出发，通过其链接进行 BFS 遍历	user_id、key、signal_type、max_depth
suggest_links	根据关键词重叠自动建议关系	user_id、min_overlap
detect_contradictions	找出相互冲突且确定性较高的事件	user_id、certainty_threshold
suggest_synthesis	查找可合并的高确定性事件	user_id、min_certainty、min_overlap
export_cluster_diagram	导出事件关系的 Mermaid 图	user_id、center_event、include_all
export_argument_outline	根据关联事件生成分层 Markdown 大纲	user_id、topic、include_evidence
get_argument_chain	追踪某个论点或主题的逻辑依赖关系	user_id、topic、max_depth

扩展上下文工具

工具	用途
save_agent_context / get_agent_context	按 agent_id 持久化和检索 Agent 的任务历史、决策及错误
save_repo_context / get_repo_context	跨会话保存代码库元数据，并按仓库进行命名空间隔离
save_service_context / get_service_context	外部服务的运行状况和状态数据
save_life_context / get_life_context	用户分享的生活模式（健康、目标、日常安排、日程）
link_resource / get_resources / unlink_resource	附加和检索与事件关联的文件、URL 和项目
add_source	为情报流水线 Pod 注册带有可信度评分的数据源
export_pod	将完整的 Pod 数据导出为 JSON（GDPR 第 20 条）
compare_pods	比较两个 Pod 中的事件——一致点、分歧和差异
get_learning_rate	显示事件基于其确定性的当前学习率

关系类型

关系	含义	示例
BUILDS_ON	A 以 B 为基础	react BUILDS_ON javascript
ENABLES	A 使 B 成为可能	python ENABLES data-science
RELATED_TO	主题关联	hiking RELATED_TO photography
CONTRADICTS	A 与 B 冲突	minimalism CONTRADICTS feature-creep
PART_OF	A 是 B 的子集	flask PART_OF python-web
EVOLVES_FROM	A 由 B 演变而来	microservices EVOLVES_FROM monolith
SUPERSEDES	A 取代 B	v2-api SUPERSEDES v1-api

事件架构

所有事件都共享相同的架构，无论信号类型如何。

{
  "user_id":          "string",          // pod identifier -- required
  "key":              "string",          // signal key -- required
  "signal_type":      "competence|preference|claim|entity|event|metric|pattern|state",
  "value":            0.0-1.0,           // signal strength -- required
  "certainty":        0.0-1.0,           // model confidence -- default 0.3
  "gloss":            "string",          // human-readable interpretation
  "validation_type":  "direct|logic",    // how error signals are produced
  "meta":             {},                // arbitrary structured metadata
  "source_id":        "string",          // source identifier (intelligence pods)
  "source_type":      "api|sensor|document|..."
}

MCP 配置

Event Pod 是一个远程 MCP 服务。通过客户端的连接器 UI 或配置文件添加它。

claude_desktop_config.json / .cursor/mcp.json：

{
  "mcpServers": {
    "event-pod": {
      "url": "https://context.nervousmachine.com/mcp",
      "transport": "sse"
    }
  }
}

由于 Event Pod 是一个远程 MCP 服务，大多数客户端都支持通过 UI 添加它，无需直接编辑配置文件。请查看客户端中的“添加集成”或“MCP 连接器”部分。

curl 示例

创建 Pod：

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method":"tools/call","params":{"name":"create_pod","arguments":{"user_id":"alice","name":"Alice"}}}'

保存事件：

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method":"tools/call","params":{"name":"save_event","arguments":{"user_id":"alice","key":"python","signal_type":"competence","value":0.8,"certainty":0.3,"gloss":"Strong Python developer"}}}'

获取 Pod 摘要：

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method":"tools/call","params":{"name":"get_pod_summary","arguments":{"user_id":"alice","include_glosses":true}}}'

应用学习：

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method":"tools/call","params":{"name":"apply_learning","arguments":{"user_id":"alice","key":"python","signal_type":"competence","error_direction":"increase","error_magnitude":0.1}}}'

隐私与数据权利

Event Pod 存储的是学习到的抽象知识，而非原始数据。你的 Pod 包含模型从交互中学到的内容——不包括对话记录、文件，也不包括你未明确保存的个人信息。

权利	工具	说明
导出你的数据	export_pod	以 JSON 格式返回完整 Pod。符合 GDPR 第 20 条。
删除你的数据	delete_pod	永久且不可撤销。需要设置 confirm: true。符合 GDPR 第 17 条。
检查存储的内容	get_pod_summary, get_events	随时全面查看所有事件及其确定性评分。
更正存储的知识	save_event, apply_learning, delete_event	可使用自然语言更新、更正或删除任何事件。

存储向量，而非对话记录。 这就像一位同事记得你擅长 Python，而且喜欢直接的反馈。他没有你的对话记录——只是了解你。你的 Pod 存储的就是这类信息。

---

Event Pod 由 Nervous Machine 打造——为 Agent 而建。我们全都是边缘案例。