Agent Quickstart
先从 context 开始，再只在必要时分流
最快的成功路径通常是一次 context 读取，再加一次任务调用。用这页判断什么时候停留在这个形态，什么时候再往深处走。
Format: AI-first docs
Source: DocsAgentsQuickstartPage
提示
默认先选最小但足够有效的工作流。
当 agent 不再每轮重建同一个职业模型时，ProfileClaw 的价值才会真正出现。
核心工作流层级
用这几层把第一版实现保持得简单、可控。
Grounding
在让 agent 做复杂动作之前，先加载一份紧凑上下文。
- 先调用 `GET /api/v1/context`。
- 让第一份 payload 保持紧凑。
- 把它作为后续调用共享的用户模型。
Specialization
只有任务真的需要更深结构时，再进入更窄的调用。
- 探索未来路径时进入 prediction。
- 需要更深分析时进入 reasoning。
- 对近期事件敏感时进入 dynamic context。
Continuation
把事件驱动和长时运行留到后面，而不是第一天就加。
- 只有异步工作流才上 webhook。
- 重试处理暂时性失败，而不是处理非法请求。
- 当重复读取变明显时再加入缓存。
把 2-call 当成默认心智模型
对大多数助手来说，一次 context 读取加一次更窄的后续调用，已经足够有用，同时也不会过度拉取。
- 先读 context，让 runtime 从档案、简历和测评信号开始。
- 只有工作流证明需要更多信息时，再进入更深调用。
- 把第一版的延迟和 token 成本压低。
把 3-call 当成证据驱动的升级
当工作流需要更强解释、近期记忆或后续续跑逻辑时，第三个调用才开始真正有价值。
- 当排序和解释更重要时，进入 `careerGraph=summary`。
- 当近期事件会影响答案时，进入 `dynamicContext`。
- 当流程要在外部变化后恢复时，进入 webhook。
工作流对比
选最窄但仍然匹配任务的流。
| 工作流 | 最适合 | 不适合 |
|---|---|---|
| 默认 2-call | 大多数助手、copilot 和第一版集成。 | 你已经明确知道它强依赖动态记忆或异步续跑。 |
| 扩展 3-call | 规划、排序或对上下文敏感的任务。 | 产品还没证明基础价值。 |
| 事件驱动 | 必须在稍后再次唤醒的长时流程。 | 目前仍然可以仅靠直接读取完成工作。 |
决策矩阵
用下面这些判断决定下一层该加什么。
情况
agent 只需要稳定用户画像
动作
停留在紧凑版 Context API 读取。
原因
它已经包含最高信号密度的 grounding layer。
情况
答案强依赖未来路径或备选方向
动作
在 context 之后分流到 prediction 或 reasoning。
原因
这些端点本来就是为前瞻性决策设计的。
情况
工作流必须在用户后续变化后恢复
动作
加入 webhook，并在唤醒后重新拉取新鲜状态。
原因
每轮轮询会浪费 token 和 runtime 工作。
参考流程
先用当前已开放的 Context API 只读 key 跑通默认 2-call。更深 scope 目前走内测 / 人工申请，不建议在第一版接入里假设已经自助开放。
默认 2-call
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,dynamicContext&careerGraph=summary&query=product%20management" -H "Authorization: Bearer $PROFILECLAW_API_KEY"下一步
默认工作流清楚后，再去调 runtime 行为和契约检查。