像入职初级工程师一样入职 AI 智能体是一种范畴错误

当一个智能体（agent）加入你的团队时，每个工程经理脑海中最接近的类比就是新员工。因此，应对策略显而易见：给它一个沙盒和只读日志，将最初的任务范围缩小，与其结对编程，预留一段磨合期，并随着信任的累积让它承担更重的工作。这听起来很负责任。这感觉就像是你把上一个初级工程师培养成高级工程师时那种耐心的管理方式。

这也是一个范畴错误（category error）——它不只是一个略显不完美的类比，而是一个错误的类比。初级工程师是一个还不太了解你系统的人。而智能体是一个无状态的函数，无论接触系统多少次，它永远都不会真正“了解”你的系统。这是两种完全不同的事物，适用于前者的管理直觉会在无形中让你错配注意力。

这之所以重要，是因为这个隐喻不仅会产生误导，还会让你把精力投在错误的地方。“培养智能体”并不是一种策略。智能体是固定的，你真正能改变的一切都存在于它之外。

类比在每一个关键维度上都失效了

首先看定义“引导”（onboarding）的属性：初级工程师会积累经验。他们定位的每一个 bug，每一个让他们搭进周末的竞态条件，每一个他们内化的 PR 评论——这一切都会沉淀下来。入职六个月后，他们掌握了从未被记录下来的隐性背景。磨合期的全部意义在于投入会产生复利。

智能体不产生任何复利。大语言模型是无状态的：每一次调用都是一个新的开始，除非显式地将历史记录放回其上下文窗口（context window），否则模型对过去的交互没有任何记忆。昨天修复了代码库中一个微妙并发 bug 的智能体，今天开始工作时掌握的知识，和你安装它的第一天一模一样。它并没有“学习代码库”。它只是在单次会话中读取了一部分代码库，随后会话结束，那些知识也随之消逝。

这在四个维度上同时打破了类比：

• 留存。 初级工程师记得昨天。智能体不记得。任何你想要它“知道”的东西，都必须在每个会话中由你重新加载。
• 隐性背景。 初级工程师建立的直觉并不存在于任何文档中。智能体没有存放直觉的地方；如果它不在上下文窗口中，它就不存在。
• 进步曲线。 随着时间的推移，初级工程师对你的系统的掌握会单调递增。而智能体在你系统上的能力是持平的。它只有在供应商发布新模型时才会进步——这是一个你无法控制也无法安排的外部事件。
• 失败模式。 初级工程师的失败曲线是平滑且可辨识的：早期生疏，稳步向好，错误可预测。而智能体的失败是爆发性的。它可能在前十步表现流畅，然后在第十一步毫无征兆地发生灾难性的错误。对编码智能体的失败分析总是发现同样的模式——级联错误，即一个糟糕的中间结果会默默地腐蚀下游的每一个决策。

最后一点是最危险的，因为爆发性失败瓦解了人类引导的核心机制：渐进式信任。你通过观察来对初级工程师建立信任——观察他们如何处理回滚，如何思考边缘情况，以及他们的判断力如何提高。这种观察之所以奏效，是因为人类的表现是自相关的。上周表现谨慎的人这周大概率也会谨慎。智能体的表现则不具备这种自相关性。完美完成十个任务，对于第十一个任务的情况几乎没有参考价值。“渐进式信任”应用于智能体，只是你在两次事故之间给自己讲的一个故事。

“智能体将学习我们的规范”这一看法的错误之处

这是智能体采用规划中最昂贵的一句话。它听起来像是一个时间表——“给它几周时间”——但实际上，这对于系统运作方式的描述是完全错误的。

智能体不会学习你的规范。它做不到。没有权重更新，没有持久化存储，也没有任何机制能让智能体在接触代码库后改变其未来的行为。当人们这么说时，他们真正指的是另一件真实但有本质区别的事情：“一旦我们将规范写在智能体能读取的某个地方，它就会遵循这些规范。”这是事实。但请注意，工作重心转移了。这种改进源自人类编写和维护的产物，而不是智能体不断累积的熟悉度。如果没有人编写这些产物，无论过去多少周，或者它接触了多少次代码，智能体都永远不会进步。

将其视为一个时间表会导致一种特定且显而易见的规划失败。团队预算了一个“磨合季度”，让智能体处理实际工作，看着它在第八周重复第一周犯过的错误，最后得出结论：这个智能体令人失望。智能体的表现完全符合规范。真正令人失望的是那个计划，因为它为一个根本不存在的学习过程预留了时间。

哪些入职直觉是通用的，而哪些是有害的

这个比喻并不完全错误，这也是它得以存在的部分原因。一些入职实践可以无缝迁移，因为它们本质上从来不关乎人：

• 清晰的规范。 精确、明确的任务描述对 Agent 的帮助与对初级工程师的帮助是一样的——它消除了猜测。这一点可以完全迁移。
• 限定范围的首个任务。 小型、边界清晰的工作单元可以限制影响范围。这对初级工程师是好习惯，对 Agent 也是——尽管对 Agent 而言，原因在于隔离风险，而非为了学习。
• 代码审查（Code review）。 在合并之前审查产出对两者来说都是不可逾越的底线。对于 Agent 来说，这应该是永久性的，而不是一个可以“毕业”跳过的阶段。

而有些直觉，如果照搬过来，则会产生积极的负面影响：

• 对重复错误的耐心。 对于初级工程师，犯两次错然后改正就是成长；你容忍重复是因为它是暂时的。对于 Agent，重复的错误不是一个阶段——它是你当前设置的一个稳定属性，容忍它只意味着你决定继续交付缺陷。面对 Agent 第二次犯同样的错误，正确的反应不是耐心，而是修改 harness（系统环境），让这种错误变得不可能发生。
• 期望复利式的熟悉度。 计划着“它下个月会对代码库更熟悉”是在为永远不会到来的回报做预算。
• 投资于个体。 这是代价最高昂的一项。对于初级工程师，花费在解释、指导和提供反馈上的时间是资本——它会在那个人内部产生复利。而花费同样的一个小时在聊天会话中引导 Agent 了解你的部署怪癖，当会话关闭时，这些资本就灰飞烟灭了。你明天、后天，甚至永远都要解释同样的怪癖。这种努力被浪费并不是因为 Agent 不行，而是因为它被投入到了一个没有底的容器里。

将学习成果转移到持久化制品中

这是一个能让 Agent 真正产生回报的认知重构：学习是真实的且值得做的——你只是放错了地方。停止尝试把它存入 Agent 内部。将其存入 Agent 每次都会重新加载的*制品（artifacts）*中。

每当你想要“教”初级工程师一些东西时，问问这个教训的持久化版本应该存在于哪里：

• 上下文文件（Context files）。 惯例、不明显的约束、你不断重复解释的部署怪癖——这些都属于 Agent 在每次会话开始时读取的文件。要保持克制：最近关于上下文文件的研究发现，自动生成的文件实际上可能会降低任务成功率，同时增加 Token 成本，即使是优秀的人工编写的文件也只能带来微小的提升。真正的胜利来自于写下那些 Agent 确实无法从代码本身推断出的信息——仅此而已。上下文文件不是脑力转储（brain dump），而是 Agent 在其可见范围之外无法获知的少数事实。
• 评估集（Evals）。 你在审查中发现的每一次突发失败都是一个测试用例。评估集（Eval）能让一次性的修正变成永久性的回归防护——这是存储在 Agent 外部的“肌肉记忆”。将推动它完成更难任务的“能力评估”与保护现有成果的“回归评估”分开。
• 工具设计。 当 Agent 误用 API 时——参数错误、顺序错误、时机错误——初级工程师式的直觉是更好地解释这个 API。而正确的做法是重新设计工具，让误用变得“无法表达”（unrepresentable）：收窄接口表面、验证输入、让危险路径需要一个默认不存在的参数。你不是在教练 Agent 如何正确使用，而是在从可能的行动空间中删除错误用法。

核心逻辑是：初级工程师的成长是内部的，你无法直观看到。而 Agent 的“成长”是外部的，完全由你代码仓库中的文件组成——这显然更好，因为外部状态是可审查、可对比（diffable）、有版本的，并且能同时共享给每一个 Agent 和每一位团队成员。当你引导一名初级工程师入职时，知识被困在一个大脑里。当你正确地“引导”一个 Agent 时，知识存在于 git 中。

管理系统，而非 Agent

实际的转变是停止询问“我如何让这个 Agent 变得更好？”，转而询问“我如何让这个 Agent 周围的系统变得更好？”。Agent 是你唯一无法改进的组件。其他一切——上下文文件、评估集、工具界面、审查门槛、任务范围——都完全在你的控制之下，也是所有真正收益的来源。

这也重构了你自己的角色。你在临时聊天中纠正 Agent 所花费的时间，是在半衰期为零的事情上虚耗光阴。而将这种纠正转化为上下文文件中的一行、一个评估案例或一个更严密的工具，所花费的时间则是投入到了可以产生复利的资本中——这些资本可以跨会话、跨 Agent、跨整个团队，甚至跨越下一次模型升级而存在，因为一个更强大的模型放入一个构建良好的 harness 中，会免费继承这一切。

因此，保留那些始终关乎工作的入职环节：清晰的规范、小规模的首个任务、强制性的审查。抛弃那些关乎人的部分：作为教学手段的耐心、磨合期、对复利式熟悉度的信念、一对一的投资。Agent 不是你正在培养的初级工程师。它是一个固定的、无状态的组件，你正在围绕它构建一个系统——当你停止尝试对它进行“入职引导”的那天，就是它开始产生回报的那天。