代理始终是第一天的雇员。是时候为此进行设计了。

截至2027年，74% 的公司预计将在某种程度上使用代理，依据最近的德勤研究。多年来，我们一直在设计和构建软件，以提升人们在应用、网站、操作系统和文档中的使用体验。现在，用户根本不是人类。这不仅仅是从仪表盘和我们为人类任务设计的受控工作流转变这么简单，它还有更广泛的影响。我们正处于一个需要为代理的运行环境进行设计的时刻，同时也 需要设计人类工作流，以有效引导代理在这些环境中的体验。

我们对代理真正需要什么才能重复且可靠地成功仍处于早期学习阶段。直觉上会把代理集成仅视为提示或 UI 问题。构建一个治理良好的执行环境 对我们文化而言是全新的领域。然而，优秀设计和优秀管理的基本原则并未改变：我们必须为代理提供清晰的上下文、明确的方向和明确的意图。

Context: Why Coding Came First

如果我们希望代理能够始终如我们所期望的水平交付，背景可以说是最重要的输入。软件开发记录的背景信息几乎是所有领域中最多的：代码仓库、API 架构、系统之间的关系、代码审查以及社区讨论。因此，AI 前沿实验室先从编码入手是合乎情理的。编码是为数不多的已经有大量书面背景的领域之一。

但正如任何软件团队的新成员会告诉你的，即使拥有所有这些数据，代理仍然缺乏那些从未被记录的潜规则所蕴含的组织记忆。这一缺口十分普遍：43% 的开发者 担心 AI 工具缺乏对其特定项目或代码库的足够上下文。隐性知识涵盖了从日常约定（例如特定任务偏好的库）到高风险的运营“幽灵”（如长期存在的深夜热修复，或看似空白却支撑自定义收入报告的数据库列）。这些上下文存在于资深工程师的脑海、最近的 Slack 讨论，甚至根本不存在，极少出现在代码库本身。

如果在软件这一最为文档化的领域都如此，那么不难理解为什么代理在许多其他行业从第一天起就难以高效工作。在医疗和法律领域，塑造日常工作的组织知识大多是通过经验学习并内化的，存在于人的经验中而非正式文档。法律代理可能不了解某位合伙人偏好的结构、语气或论证方式；医疗代理可能不理解繁忙诊所用于支持临床主导分诊的本地工作流和升级实践。仅靠文档无法弥合这一差距，因为挑战不在于获取信息，而在于上下文的转移。要让代理获得成功所需的条件，我们必须像对待新雇员一样对其进行入职培训。

Direction: Why Osmosis Doesn’t Work

为新同事提供入职培训不仅仅是提供合适的材料和访问权限。当我们对周围人的成功投入关注时，会提供明确的方向：对新材料和访问的使用期望、我们想要达成的目标的清晰阐述，以及过程中的反馈。我把同样的思维方式带到为代理设计上。针对具体任务，我会给出清晰、具体的指示。这对任何同事都适用，无论其任期长短。但在新雇员的情境下，指示必须走得更远，因为他们尚未拥有任何组织上下文。

把代理想象成永远不会“成熟”的新雇员。它充满热情且能力出众（说实话，精力无限），但它无法像人一样随着时间积累并保留大量潜规则。人类通过渗透和经验学习，而代理则从明确构建在其工作环境中的架构中学习。

对于新雇员，你可以通过提问、反馈以及他们在组织流程和偏好中逐步获取的新洞见来随时间弥合这一差距。比如咖啡机旁的聊天或团队午餐。对于代理，你必须把弥合差距的机制内置到设计本身。这可以包括：

• 为代理提供结构化的上下文窗口，将持久规则、任务特定事实和相关历史分离，而不是直接把一堆文档塞给它。
• 提前定义其权限和决策边界：哪些可以独立完成，哪些需要审批，哪些绝对不能访问。
• 在体验中嵌入少量具体的高质量输出示例，让代理拥有明确的工作模型。
• 分享你曾经遇到的死胡同。

构建治理良好的代理环境并不是为了让模型更轻松，而是为了保护人类工程团队免受隐形技术债务的侵蚀。但即便是指示明确的代理，也可能完美执行指令却仍然偏离要点。指示告诉它该做什么，却没有告诉它“好”是什么样子。这正是意图发挥作用的地方。

Intent: Why Agents Drift to The Middle

必须记住，代理本质上是模式匹配机器，经过海量知识的训练，自然倾向于输出统计平均值。若缺乏清晰、明确的意图，这种平均输出正是代理会返回的结果。让代理“添加用户认证端点”，它会生成一段教材式的 Express 路由并进行基本的密码哈希。虽然能运行，但它完全忽视了你团队的自定义认证服务，跳过了必需的遥测，并破坏了你们统一的错误格式化。表面上看是一个合格的功能，但在具体上下文中却是架构缺陷。此类“bug”轻易产生的原因不容小觑。

为防止这种情况，指示必须与主动的意图验证和日志记录相结合。防护栏不应仅检查代码是否能够编译，尽管这很重要。防护栏必须明确强制执行有主见的标准、边缘案例规则以及提升通用输出至可投产工作的领域上下文。日志对于我们人类而言是系统状态指示器，这种可追溯性对信任至关重要。

在人际交互中，往往存在大量不确定性。有人可以先给你一个初版，你们一起讨论哪些地方强、哪些需要改进。这之所以可行，是因为我们并不期望人类同事是完全自主的机器。要真正释放代理同事的潜力（我们确实需要它们更自主地运行……），可以在这些指示检查上进行工程化。来回沟通仍然必不可少，但不能全部依赖人工。通过预先加载清晰的验收标准和验证规则，你让代理能够自行运行内部反馈回路。设计错误预防 是我们在新环境中可以采用的另一条可靠的 UX 原则：赋予代理在提交操作前标记低置信度的能力，而不是默默地默认最佳猜测。

Where the Metaphor Breaks

新雇员的类比在一定程度上有效，但并非永远成立。对于人类雇员，经验带来能力，能力带来判断。观察新雇员内化上下文和指示背后的“为什么”，是随着时间建立信任的过程，这本质上是累积的。而代理没有地方去累积和存储这些经验。

新雇员的第一周与第一百周的表现截然不同。代理的第一项任务与第一千项任务看起来完全相同，除非你设计并构建出让它们产生差异的机制。这正是我们面临的全新设计挑战。

Agent Responsibility Hinges on Design

如果责任无法内嵌在代理本身，就必须体现在其周围的支撑结构上。归根结底，这与我在交付任何新雇员工作前会问的三个问题相同：他们拥有怎样的上下文？我给了他们什么指示？我的真实意图是什么？

下次把任务交给代理时，别只检查输出。先检查自己的输入。你是否提供了新雇员第一天所需的上下文？你的指示是否足够具体，能够经受字面理解的考验？你的意图是否足够明确，以至于“中位答案”不是它能做到的最佳结果？

有了这些明确的指导（以字节计？），会出现有趣的现象：代理不需要漫长的适应期就能获得可信度。你事先构建的上下文、指示和验证决定了它在每项任务上的运作方式。新雇员会随着时间赢得你的信任；而代理必须在每一次通过你设计的系统时赢得信任。责任不是它逐渐成长的东西，而是从一开始就内置的。问题不在于你的代理何时准备好承担更多责任，而在于你是否设计了让它在每一次任务中都能赢得责任的机制。