一个下午，把一个真实的人接进你的 harness

每篇讲上下文层的文章听起来都像architecture布道，直到有人问“周二下午版本”：我到底调哪个接口，返回什么？这篇就是那个版本。集成本身真的很小——真正花心思的是围绕它的那些决策。

一把 key，一个 scope

在 ProfileClaw 后台创建客户端、签发 key。关键的一步往往被跳过：在需要之前，先选好这把 key 能读哪一层。从 summaries 开始。如果你的 harness 后来证明需要数字——匹配、排序、一切定量任务——再单独签一把 scope 为 scores 的 key。两把窄 scope 的 key 胜过一把宽 scope 的，理由和任何时候都一样。

走 REST 读取

Context 端点只返回 key 的 scope 允许的层，多一层都不给：

curl https://profileclaw.com/v1/context?layers=summaries \
  -H "Authorization: Bearer <client-token>"

返回的是一份带版本、分层的画像——叙事摘要连同它依据的分数，每项都带置信度和 schema 版本：

{
  "layers": ["summaries"],
  "summaries": {
    "direction": "研究型 + 艺术型画像；最适合深耕型产品工作。",
    "constraints": ["远程优先", "不值班"]
  },
  "confidence": 0.81,
  "version": "2026-06"
}

这份返回里有两个字段，值得比通常更多的注意。confidence 告诉你这次测量能承载多少权重；version 告诉你它出自哪一版计分方法。忽略它们的 harness，是在凭感觉做个性化。

或者走 MCP

如果你的客户端说 MCP，那就完全没有集成代码这回事：把 ProfileClaw 的 MCP server 加进客户端配置，本人登录一次，你的工具就出现了——以原生工具调用的方式读取上下文，scope 在登录时授予。任务需要上下文时调用工具；这次读取是新鲜的、经过授权的、和任何 REST 调用一样有日志的。

什么时候读，什么时候问

时机问题比传输问题更重要。每一轮都读一遍既浪费又吓人；自然的时点是任务开始——harness 读一次，把读到的装进工作上下文，然后专心干活。

而当画像回答不了某个问题时，正确的动作是问本人，而不是猜。上下文层缩小的是“诚实猜测”的空间，不是编造的许可证。读了上下文层之后还能提出好问题的 agent，才是用户会留下的 agent。

尊重版本

画像会改进。当你缓存的副本对应的 schema 版本变了，重新读。把 version 字段当作 cache key 对待——它的作用就是那个。过期的个性化比没有个性化更糟：它自信地描述着一个人曾经的样子。

整个集成就是这些：一把窄 scope 的 key，一个端点或一个 MCP server，任务开始时的一次读取。代码只需要一个下午。真正值得花一周的，是那个设计决策——你的 agent 被允许知道什么，以及什么时候它应该去问。