OpenClaw 集成
让 ProfileClaw 负责上下文，让 OpenClaw 负责行动
最干净的接入边界其实很简单：ProfileClaw 提供可持续信任的职业上下文，OpenClaw 在其之上负责规划、工具编排和面向用户的动作。
Format: AI-first docs
Source: DocsIntegrationsOpenclawPage
完成
当每一层只做一件事时，集成效果最好。
ProfileClaw 不应该变成整个 agent；它应该成为 agent 长期依赖的上下文提供层。
层级职责
让每个系统都只对自己该负责的部分保持明确意见。
ProfileClaw
负责身份、上下文、职业结构和契约级读取表面。
- 会话起点优先是 Context API，而不是聊天历史重建。
- 只有在必要时才升级到 prediction 或 reasoning。
- 把它作为长期职业状态的正式来源。
OpenClaw
负责计划、工具分流、对话流程和执行循环。
- 工具选择和编排逻辑应留在 agent runtime。
- 把 ProfileClaw 响应当作可信输入，而不是直接 UI 脚本。
- 通过显式编排逻辑恢复工作流。
Shared Boundary
两者之间的交接边界必须可检查、可解释。
- 用 docs 理解架构姿态。
- 用 Reference 精查字段。
- 用 OpenAPI 做工具生成和测试。
把 ProfileClaw 作为 context provider
OpenClaw 应从一次 ProfileClaw context 读取开始，而不是每次都试图从聊天历史里重建同一个职业身份。
- 在会话开始或高价值动作前先读 context。
- 把 summary 作为 prompt 和工具路由的 grounding layer。
- 除非已经证明必要，否则第一版集成保持在 compact reads。
上下文加载后再按任务分流
一旦 agent 拿到了稳定用户画像，它就可以根据真实任务意图选择更窄的 ProfileClaw 调用，而不是按记忆里的端点熟悉度分流。
- 探索未来路径时进入 prediction。
- 需要更深叙述分析时进入 reasoning。
- 流程要跨时间持续时再进入 alerts 或 webhooks。
边界对比
健康的集成应把 context 和 action 的所有权分开。
| 层 | 应该负责 | 不该负责 |
|---|---|---|
| ProfileClaw | 上下文读取、归一化职业结构和契约表面。 | 对话控制或 UI 级执行规划。 |
| OpenClaw | 工作流编排、工具选择和用户动作循环。 | 从零开始长期重建职业身份。 |
| Integration boundary | typed 请求、清晰路由和可观测交接。 | 依赖纯 prompt 的隐式耦合。 |
决策矩阵
设计或排查边界时，可以用这些规则判断。
情况
agent 需要稳定职业画像
动作
在选择下一个工具前先读 Context API。
原因
它提供最高信号密度的共享用户模型。
情况
工作流开始转向未来决策或解释
动作
在 context 之后进入 prediction 或 reasoning。
原因
这些 API 本来就是为决策深度和解释深度设计的。
情况
集成开始变得难以理解
动作
重新检查哪一层负责 context，哪一层负责 action。
原因
边界漂移是隐藏复杂度的常见来源。
最小集成路径
当前公开自助能力以 Context API 只读 key 为主，适合先把 OpenClaw 风格 runtime 跑通。reasoning、prediction 或 webhooks 等更深 scope 目前走内测 / 人工申请。
加载上下文
1
curl "https://api.profileclaw.com/api/v1/context" -H "Authorization: Bearer $PROFILECLAW_API_KEY"扩展上下文
1
curl "https://api.profileclaw.com/api/v1/context?expand=careerGraph&careerGraph=summary" -H "Authorization: Bearer $PROFILECLAW_API_KEY"下一步
当架构边界清楚后，再去检查 agent 工作流和契约细节。