5 Rules for Building AI Agents That Work in Production | Nan Yu & Jacob Shumway

Linear 在 Slack 里 @ 一下 Agent，它自己读上下文、建 ticket、写代码，6 分钟直接产出可点击的 PR，全程不用打开 Linear。

最强 Agent 不是聊天，而是接管工作流

Nan Yu 与 Jacob Shumway 来自 Linear，逐字稿没有披露二人的正式头衔。Nan 写下了 Linear Agent 的早期构想 memo，Jacob 则参与了从“前端直接调用 LLM”的粗糙原型，到可在生产环境运行的架构实践。他们讲的不是怎样把聊天机器人塞进产品，而是怎样让一个 Agent 在 Slack 讨论、项目管理、代码仓库之间接住工作，并且不把团队拖进新的混乱。

这期回答了 7 个问题：

1. 为什么模型已经足够聪明，企业却仍然没有真正用好它？
2. 给 Agent 更多提示词和上下文，为什么反而可能让它变笨？
3. 如何让 Agent 自己去找所需信息，而不是把所有资料塞进 prompt？
4. 为什么要先用最大模型，再逐步换成更小、更便宜的模型？
5. 原生 Agent 相比 MCP 工具集合，真正多出来的能力是什么？
6. 为什么 Agent 做完代码后，任务仍应归属某个具体的人？
7. 当 Agent 开始长期运行，如何避免仓库被 AI 生成的“文档垃圾”淹没？

被问到 Linear Agent 上线后，团队究竟在评测什么问题时，Nan Yu 没有先谈模型分数。他说，眼下更大的问题是“capability overhang”或“capacity overhang”：模型已经很能干，人却没有把足够多的工作交出去。"The models are really smart, but we're just not using them enough."（模型真的很聪明，但我们根本没有充分使用它们。）

Linear 的评测重点，因此不只是“它能不能答对”。用户在 Slack 里说一句话，可能是在提问，也可能是在暗示“把这件事推进下去”。Agent 要判断用户真正想完成什么任务。反过来，它也不能太热心：一个用户只是问了后续问题，Agent 却擅自新建任务、调动工具、触发昂贵操作，体验会立刻变成打扰。

Slack 场景尤其能说明这个难处。Agent 即便觉得自己知道答案，也会经过内部判断：自己到底该不该插话。人类同事不是每句话都要抢着接，工作型 Agent 也一样。

这意味着，企业竞争的焦点不只是“接了哪个更强的模型”，而是能否把模糊意图转成可授权的行动。Agent 的能力不是一个静态分数，而是判断何时该动、动到哪一步的分寸感。授权太少，模型像被锁在玻璃柜里的工具；授权太多，它又会替用户做出并不想要的高成本决定。

被问到早期把 Linear 的大量能力直接交给模型后，为什么仍然出现上下文问题和幻觉时，Jacob Shumway 讲了一个很典型的弯路：团队曾试图把 Linear 里几乎所有动作都开放给 Agent，也试过把 GraphQL schema，也就是数据库查询接口的结构说明，交给模型，让它自己写查询。但效果并不好，模型面对过多工具、规则和资料，反而更容易跑偏。

他们后来形成的原则很硬："Give it as little instruction as possible. Give it the tools to load context. Don't give it context."（尽可能少给它指令。给它加载上下文的工具，但不要直接把上下文塞给它。）

Jacob 对 Agent 的技术定义是：给定目标和工具后，让 LLM 在循环中不断调用工具、拉取信息，直到它认为目标完成。它不是一次性收到一大包项目资料，再被要求“自己看着办”；而是先知道要完成什么，再去读相关 Slack 讨论、项目描述、已有 issue 或代码库。

这意味着，生产级 Agent 的 prompt 不该像塞满附件的公文包，而应更像一张任务单加一串钥匙。上下文由任务动态装配，减少不相关信息对模型注意力的挤占。但前提也很苛刻：工具边界、检索能力和目标定义必须靠谱。Agent 找不到该找的信息时，“少给上下文”不会带来聪明，只会带来信息不足。

被问到 Linear 为什么混用不同模型，以及如何评估“创建 issue”是否做好时，Jacob 给出了一条很务实的顺序。早期大约 80% 的使用场景都和创建 issue 有关，于是团队做了一个小型 router，也就是请求分流器：识别出这类需求后，将其送进专门优化的 subprompt，而不是每次都走功能最全、成本也最高的通用路径。

但分流不是一开始就为了省钱。"We tend to throw the biggest model on it until we know that it's working well."（我们通常先把最大的模型扔上去，直到确认它确实运作良好。）先用能力最强的模型验证任务能不能成立，建立 eval，也就是自动化评测，再逐步把模型降级到更小、更便宜的选择。

Linear 的评测分两类。用户说状态要设成“in progress”，系统就检查状态是否确定地被设为 in progress，这属于可机械判定的标准。标题是否抓住重点、描述结构是否合理，则会使用 LLM as a judge，也就是让另一个模型按标准打分。用户以意料之外的方式使用 Agent，也会被加入评测数据集。

这意味着，模型选型不该是项目的起点，而是验证后的成本优化。高频路径一旦被证明有效，才值得压缩成本。不过团队也刻意少用主观模型评测：不是每种表达差异都是错误。把所有不一致都当坏结果，只会把 Agent 训成格式正确但反应僵硬的机器。

被问到 Linear 为什么不只提供 MCP 或接入外部编码 Agent，而要自己构建原生 Agent 时，Nan Yu 的答案落在“方法论”上。MCP 可以理解为让外部 AI 调用产品工具的一套连接方式；它能让别的 Agent 创建任务、读取信息，却不自动懂得 Linear 认为“好工作流”应该长什么样。

Linear 为不同任务写了 skills。比如创建 issue，不只是调用“新建”按钮，还要带着对优先级怎么设、描述怎么写的明确判断。团队认为，原生 Agent 可以拥有数百个 skills，并按任务动态加载，形成一种平滑而且“有主见”的使用方式。"You can just have linear itself execute the playbook."（你可以直接让 Linear 自己去执行这套打法。）

过去，Linear 会通过《Linear Method》一类指南，告诉用户怎样管理软件开发流程。现在，这些原本写在文档里的流程偏好，可以被编码进 Agent：从讨论里提取决策、放进合适项目、更新相关信息，再衔接后续代码工作。外部 Agent 可以写代码，也能对 bug 做 root cause analysis，即根因分析；但未必能覆盖 Linear 想管理的完整软件开发周期。

这意味着，垂直 Agent 的差异化不只在模型和 API，而在于公司能否把自己的判断标准做成可执行能力。边界同样明显：方法论越强，越可能把某一种团队偏好硬套给所有人。所谓“有主见”，必须允许用户保留自己的做法。

被问到 Linear Agent 最早如何上线，以及用户为什么会发现团队没预料到的用法时，Nan Yu 提到，他们没有先办一场大发布。第一个生产版本只是悄悄接入已有的 Slack integration。用户在 Slack 里 @linear，才会发现它已经能做事。这个入口很小，却正好落在团队讨论、争论和作出决定的现场。

用户很快不满足于“帮我创建 issue”。有人在一段讨论后只说“Linear, do the right thing”，也有人只 @linear 再加一个向上指的 emoji。Agent 会结合整段对话，判断该把什么问题整理成任务。客户还把它用于翻译：面对法国客户发来的 Intercom 工单，可以设置自动化流程，在创建 issue 前先把法语内容翻译出来。

Nan 的判断是："The entry points are in the discussion that you're having in Slack or in your meeting debrief."（入口就在你正在 Slack 里进行的讨论，或会议复盘之中。）聊天框当然仍然必要，复杂任务需要多轮追问；但聊天框只是一个交互表面，不是唯一入口。

这意味着，Agent 的采用率取决于它是否嵌进既有行为的接缝处。人在 Slack 讨论、写项目更新、复盘会议时，本来就在生产上下文。Agent 出现在那里，需求会自己冒出来。若只等用户专门打开聊天窗口，它就像被放在办公室另一头的同事：能力可能不差，但总是来得太晚。

被展示一次 Slack 讨论如何从模糊想法变成 issue 和代码 PR 时，Nan、设计师 Yan 与 Jacob 正在讨论一个界面问题。他们来回提出方案、表达异议、澄清真正的症结，最后没有把完整需求重新写一遍，只要求 Linear："Write the issue and work on it."（把 issue 写出来，然后去做。）

Linear 根据整段 Slack 讨论创建 issue，作出相应决策，将任务分配给 Jacob，同时把执行工作委派给自己。6 分钟后，它给出一个可点击查看的 PR，也就是待审查、待合并的代码改动申请。这个过程看似已经把“从想法到代码”交给了 Agent，但 Linear 没有把责任从人身上抹掉：issue 仍在 Jacob 的个人 backlog 和 to-do 状态里。

这样设计是为了避免任务被埋在 Slack。聊天会不断往前滚，一条没有进入项目系统的决定，很容易被后续消息淹没。Jacob 作为拍板启动这项工作的人，仍有一个可以追踪、审查和接手的 handle。

这意味着，组织不会简单地把任务“分配给 AI”，而会形成新的责任分层：Agent 执行、衔接、整理，人保留启动决策、优先级判断和最终验收。例外也存在。Datadog 告警自动触发 bug 后，Agent 可以一路处理到最终 review 前都无人介入。因此，谁对结果负责，不取决于是否用了 Agent，而取决于任务是由谁、以什么方式启动的。

被问到长时间运行的 Agent、自动计划和不断生成 markdown 文档会不会带来新问题时，Jacob 说团队正在内部实验围绕 loops 和 goals 的能力，也就是让 Agent 围绕目标持续循环推进，而不是只完成一次请求。但运行时间一拉长，成本问题立刻出现：模型调用要花钱，持续检索和反复行动也会不断消耗资源。

Nan 更担心另一种账单：认知账单。Agent 很擅长生成 markdown 文档，代码仓库里会越来越多计划、总结、说明和中间产物。问题不在于它们能不能写出来，而在于人还会不会读。"it just turns to slop, dude. That that's what happened."（它最后就会变成一堆垃圾，兄弟。事情就是这样。）

如果 AI 生成的文档继续被下一轮 AI 当作上下文，再生成更多文档，仓库会像不断复印又不断加注的文件柜。细节越来越多，可读性却越来越低。原本为了减少工作而引入的自动化，最后把筛选、辨认和清理的负担推回给人。

这意味着，下一阶段的 Agent 工程难题不只是“让它做更多”，还包括信息淘汰、可读性标准和人工审查机制。嘉宾没有给出成熟解法，这恰恰是现实边界：他们一面在试验长期 loops，一面已经感受到成本和内容失控的风险。

被问到 Linear Agent 下一步会建设什么能力时，Nan Yu 点了两个方向：proactivity，也就是不等人下指令、能在合适时机主动推进；以及更长时间运行的 memory，也就是跨越更长周期保留项目脉络。一个项目可能几天结束，也可能持续整整一个季度。若 Agent 只记得最近一轮对话，它再会写 issue，也管不好一个不断变化的项目。

Linear 想要的不是一个“随叫随到的任务执行器”，而是能理解项目全周期发生过什么的系统。它要能在需要时协调人员，推动项目往前走，确保相关文档保持更新。Nan 对最终体验的描述很直接："I can take for granted that it's wellrun, right?"（我可以理所当然地认为，它被运行得很好，对吧？）

这句话把衡量标准从单次输出拉长到时间维度。一次任务写得漂亮，不代表项目会顺利；真正难的是人员变化、讨论更新、优先级调整后，系统还能否保持信息同步、工作不断档。

这意味着，Agent 的价值将从“这次回答得好不好”转向“它能不能维持项目秩序”。不过这仍是 Linear 正在投入的方向，不是已经完成的承诺。长期记忆、主动性和成本控制必须同时成立：它既要记得足够多，又不能把旧信息和无效动作无限积累下去。

把“提示词越长未必越稳，关键是让 Agent 自己取上下文”和“Agent 不该等用户打开聊天框，而要埋进工作真正发生的地方”放在一起看，Linear 的路线很清楚：Agent 不应坐在一个孤立聊天框里，等用户搬运资料、重新描述任务。它应该出现在 Slack 讨论、会议复盘、项目更新这些上下文本来就产生的地方，再按需去找代码、任务和项目资料。

再把“原生 Agent 的护城河，不是工具更多，而是能执行产品方法论”与“Agent 可以完成工作，但决策责任仍必须挂在人身上”放在一起，事情就不只是自动化。Agent 可以执行团队对优先级、任务描述和协作流程的判断，但它不该偷走人的决策责任。它负责把讨论变成行动，把行动接进系统；人负责决定什么值得做、何时接受结果。

对正在做 Agent，或准备把 Agent 引进团队的人来说，最该先画出来的不是 prompt，而是工作流：一个决定从哪里出现，会经过哪些系统，谁要拍板，哪些信息必须留下，哪些内容必须被淘汰。模型只是发动机。真正决定它能否可靠跑下去的，是你有没有把路、路标、责任人和清理机制一起建好。