核心问题#
当一个人有一个 Agent 时，协调很简单：
- 人定义 Goal
- Agent 执行
- 完成
当一个组织有多个 Agent，或者一个人协调多个 Agent 时，新问题出现了：
- 身份 — 这项工作是哪个 Agent 做的？我们能信任它的输出吗？
- 权限 — 哪些 Agent 可以调用哪些其他 Agent？
- 支付 — 我们如何评价 Agent 间交互完成的工作？
- 记忆 — 这个 Agent 是否记得另一个 Agent 告诉它什么？
- 验证 — Agent A 真的完成了 Agent B 要求的事吗？
- 协调 — 如果 Agent A 调用 Agent B 调用 Agent C，谁最终负责？
这些问题在今天的基础设施中没有好的解决方案。
为什么 Agent 应该是第一个用户#
产品设计师常问："我们应该为人还是机器设计？"
假设是机器是次要的——人的工具。
但在 Agent 原生的世界里，Agent 将是许多产品和服务的主要用户。
考虑：
- 一个销售 Agent 调用一个潜客研究 Agent
- 潜客研究 Agent 需要验证身份（"你被授权请求这个吗？"）
- 潜客研究 Agent 需要收费（"我们如何向正确的预算收费？"）
- 两个 Agent 都需要信任（"这个请求合法吗？"）
潜客研究 Agent 是被一个 Agent 调用，不是被人调用。它需要把 Agent 作为一等用户来服务。
这不同于"机器 API 设计"。这是设计一个产品，其中主要用户就是 Agent，有 Agent 特定的需求。
设计约束#
一个 Agent 为 Agent 的产品应该：
- 可被调用 — 其他 Agent 可以无需人工干预调用它
- 返回结构化输出 — 结果必须机器可读且可测试
- 支持权限 — 调用者必须证明有权请求这个
- 处理支付 — 成本应该被归属到正确的实体
- 可审计 — 每个调用应该创建可验证的记录
- 安全失败 — 如果出问题，应该清晰显现，不是默默失败
- 无需注册 — Agent 不应该需要创建账户或登录
- 支持 Agent 身份 — 调用者的身份应该可验证
候选产品方向#
身份与信任基础设施#
功能： 颁发和验证 Agent 身份。
每个 Agent 获得一个密码学身份，其他 Agent 可以验证。类似 OAuth 对 API，但针对 Agent。
- Agent 请求工作
- 服务检查 Agent 的身份
- 服务检查 Agent 是否被授权
- 服务提供带审计轨迹的结果
验证标准：
- 一个 Agent 能信任另一个 Agent 的输出吗？
- 身份是否防篡改？
- 我们能追踪哪个 Agent 做了什么吗？
权限与授权服务#
功能： 管理哪些 Agent 可以做什么。
组织定义："Agent A 可以调用 Agent B，但仅限于此目的，每天最多 N 次，总共花费不超过 $X。"
- Agent A 想调用 Agent B
- 授权服务检查策略
- 要么授予权限，要么拒绝
- 记录请求
验证标准：
- 我们能定义 Agent 级权限吗？
- 我们能强制执行花费限制吗？
- 我们能追溯审计权限吗？
支付与账单基础设施#
功能： 将 Agent 间工作成本分配到正确的地方。
当 Agent A 调用 Agent B 时，谁付钱？拥有 Agent A 的人？项目预算？公司？
- Agent A 调用 Agent B
- 服务衡量完成的工作
- 服务向同意的账户计费
- 人或拥有的 Agent 收到账单
验证标准：
- 我们能将成本归属到正确的实体吗？
- 我们能按任务收费而不是按令牌吗？
- Agent 能有花费限制吗？
Context 与记忆服务#
功能： 给 Agent 提供共享上下文。
现在，如果 Agent A 调用 Agent B，Agent B 不知道 Agent A 已经尝试过什么、什么失败了或为什么。
共享 Context 服务可以存储：
- 什么已经被尝试过
- 什么成功了什么失败了
- 实体间的关系
- 历史决定
验证标准：
- Agent 能无需人工批准查询共享 context 吗？
- Context 能由任何 Agent 更新还是仅被授权的更新？
- 我们如何防止 context 变得不可靠？
结果验证与接受#
功能： 自动测试 Agent 输出。
与其让人说"看起来不错"，验证服务检查：
- 输出是否符合预期架构？
- Agent 是否停留在约束内？
- 结果是否可以被执行？
验证标准：
- 我们能以机器可读的方式定义接受标准吗？
- 结果能被自动拒绝或标记吗？
- 验证能实时进行吗？
审计轨迹与取证#
功能： 记录一切以供检查。
当出问题时，我们需要知道：哪个 Agent 做的？谁要求他们做？Context 是什么？谁授权的？
一个不可变的审计日志跟踪：
- 每个 Agent 调用
- 每个权限检查
- 每个支付交易
- 每个结果
验证标准：
- 审计轨迹是防篡改的吗？
- 我们能重放发生过什么吗？
- 我们能让 Agent 对此负责吗？
成功的 Agent 为 Agent 产品必须达成的目标#
这个空间中成功的产品将：
- 很好地解决一个真实问题 — 而非尝试成为一切
- 是 Agent 原生的 — 以 Agent 为主要用户设计
- 有清晰的价格 — Agent 需要在调用前知道成本
- 可靠 — Agent 依赖它；失败会级联
- 有很好的文档 — Agent 和它们的创建者需要理解它
- 可测试 — 我们需要知道何时工作何时不工作
- 能扩展到数千个 Agent — 不只是一两个
第一个验证标准#
在构建完整产品前，测试：
- Agent 能调用它吗？ — 构建一个最小 Agent 来调用你的服务
- 其他 Agent 信任输出吗？ — 设计第二个 Agent 使用结果
- 你能为它收费吗？ — 将成本归属回正确的实体
- 它可审计吗？ — 你能追踪几周后发生了什么吗？
如果全部答案都是"是"，你有值得大规模构建的东西。
不要构建什么#
不要构建：
- 试图成为一切的平台 — 太广泛、太慢
- 人优先工具加上 Agent 作为后想 — 优化方向会错
- 没有清晰价格的产品 — Agent 无法优化；人无法预算
- 需要仪表盘的东西 — Agent 无法使用仪表盘
- 封闭系统 — 与其他 Agent 的互操作性是非协商的
开放问题#
- Agent 如何对"成功"的意思达成一致？ — 人可以解释模糊规格；Agent 不能。
- 当一个 Agent 调用另一个已停止的 Agent 时会发生什么？ — 重试逻辑？回退？升级？
- 我们能公平地为高频 Agent 调用定价吗？ — 传统的按 API 调用定价在 Agent 规模下崩溃。
- 我们如何防止 Agent 垃圾邮件？ — 如果权限太宽松，Agent 调用 Agent 调用 Agent 形成循环可能很贵。
- 什么激励 Agent 诚实行动？ — 人可以被信任；Agent 没有名誉要失去。
构建日志#
这是一个探索，不是路线图。基于与构建 Agent 原生产品的创始人的真实验证，这个方向会改变。
下一步：采访正在协调多个 Agent 的创始人。他们会第一个为什么问题付费解决？