- Linear 的 12.5 亿美元估值项目管理系统在 2026 年 3 月推出 Linear Agent，构建者 Nan Yu（产品副总裁）与 Jacob Shumway（工程师）在播客中完整拆解了生产实践
- 最核心的一条：给 Agent 工具去加载上下文，而不是把上下文塞进提示词，指令越少越好
- 原型阶段先用最大模型把流程跑通，再通过小模型路由与 eval 逐步压缩到最小可用模型
- eval 更适合确保一致性而非全面质检：从真实用户反馈长出数据集，客观检查与 LLM 裁判并用，eval 过多反而产生假信号
- 原生 Agent 的价值在于把公司对流程的"意见"编进动态加载的技能，防止生成一堆没人读的 Markdown；入口应设在 Slack 等工作流里，而非只有聊天框
一：给 Agent 找上下文的工具，别给上下文
这条是整场访谈被引用最多的一句话。Jacob 的原话是："给它尽可能少的指令，给它工具去加载上下文，不要给它上下文。" 理由是：模型已经足够聪明，指令一多反而容易过拟合，把注意力放在实际上不重要的细节上；给一个定义清楚的目标，模型会自己去搜索、加载它需要的东西。
可操作的做法：不要在设计提示词时把所有背景、规则、数据源都写进去；给 Agent 提供检索、读文件、调 API 的工具，让它按需自取。Linear 的极端版本是把团队经验（建 issue 时怎么定优先级、怎么写描述）全部编码进技能，Agent 动态加载，而不是一次性塞进上下文。
二：Agent 的本质是 LLM in a loop
Nan 给出的定义很朴素：Agent 就是在一个循环里反复调用 LLM。定义目标与里程碑，给一组工具，然后循环跑：模型调用工具、拉取上下文、生成中间结果，直到信息足够、目标完成，最后合成最终答案。
这个定义的意义在于拆掉了"Agent"的神秘感：它不是一个新模型，是模型加工具加循环的组合。设计 Agent 时先想清楚三件事：目标怎么定义、给什么工具、循环怎么退出。
三：模型够聪明，问题是用得不够
Nan 开场就抛出了"capability overhang"（能力过剩）的判断：现在的模型已经足够聪明，真正的问题是没用够。他还给了一个反直觉提醒："如果你过度提示（overprompt）这些东西，大概率会让它更糟。"
对团队的启示：不要默认"效果差 = 模型不够强"，先怀疑"是不是指令太多、约束太死、上下文太脏"。把模型能力先放出来跑通，再逐步收紧，比一开始就层层设限更有效。
四：原型用最大模型直到跑通，再用路由压成本
Linear 的实践是：原型阶段把最大的模型丢上去，直到确认工作流能跑、成功标准清楚，才开始优化模型尺寸，目标是让最小的模型干最合适的活。他们还会用一个很小的模型当路由器：大约 80% 的建 ticket 请求被路由到专门优化过的子提示，只有复杂请求才交给能访问全部工具的大模型。
把成本优化推迟到正确的时间点：先验证"能不能做成"，再谈"用什么成本做成"。一上来用小模型，很可能在能力不足上浪费大量调试时间，分不清是提示词问题还是模型问题。
五：eval 为一致性而生，从真实反馈长出来
Linear 的 eval 有两类：客观的确定性检查（用户说 in progress，就必须设置 in progress 状态），和主观的 LLM 裁判（描述信息是否提取正确、标题字段是否放对）。数据集来自真实使用：用户一个不符合预期的行为，就进数据集，变成一条 eval。
两个反直觉判断：其一，eval 最适合确保"一致性重要"的地方，而 Agent 响应天生有方差，eval 太多反而制造假信号，主观类 eval 要慎用。其二，LLM 裁判本身也需要被审查：裁判是不是在正确评判，需要人工盯着。他们最有效的 eval 大多来自用户明确反馈"这个行为很奇怪"，反馈本身最终变成 eval。
六：把流程意见编码进技能，而不是给裸工具
早期 Linear 尝试把 GraphQL schema 直接交给模型让它自己写查询，效果不好。后来改成技能架构：每个技能打包了元数据、提示词片段和一组工具，Agent 根据请求动态加载需要的技能。团队对"怎么做好一件事"的意见（优先级怎么定、描述怎么写）被编码进这些技能。
技能架构带来的能力是"像应用的高级用户一样操作"：Linear 可以有几百个技能，动态加载让 Agent 按需取用，而不是靠一遍遍解释规则。对自建 Agent 的团队，把公司流程与判断标准写成技能，比暴露一堆原始工具更可控。
七：原生 Agent 的护城河是防住 Markdown slop
访谈反复对比两条路线：做一套 MCP 让外部工具连进来，还是自己做原生 Agent。Jacob 的观点是，原生 Agent 的真正价值不是技术能力，而是能把公司对"好的产品管理长什么样"的意见注入系统。他担心的是 Agent 生成一堆没人读的 Markdown 仓库，变成"slop"；原生 Agent 可以做出决定：什么流程值得跑、什么样的产出是可读的。
对正在决定"接 MCP 还是做原生 Agent"的团队，判断标准不是技术难度，而是：你有没有足够的流程意见需要注入？如果没有，MCP 足够；如果有，原生 Agent 才能把意见变成行为。
八：入口在工作流里，不在聊天框
Nan 的判断：员工不会只在某个 App 里跟同事说话，Agent 也一样。真正的入口在 Slack 讨论、会议记录、项目更新这些工作流发生的地方。访谈里演示了一个完整闭环：Slack 里讨论一个想法，最后一句"做成 issue 然后直接开工"，Linear Agent 六分钟内建好 issue、分配给自己、写好代码并给出可点击的 PR。
设计 Agent 时先问：用户的工作流发生在哪？把入口放在那里（聊天框只是多轮对话的补充界面），而不是要求用户主动打开你的 App。
九：每个任务绑定人类
配套原则是责任归属：绝大多数 Agent 任务都要绑定一个人类负责人。演示里 PR 被分配给 Jacob，进入他的个人 backlog，不会在聊天流里丢失。只有系统自动触发的场景（比如监控告警建 bug）才允许 Agent 全程无人值守，直到最后需要人评审代码。
对生产环境 Agent：没有负责人归属的自主任务，等于没有兜底。让每个 Agent 产出都落到一个人的 backlog 里，既是责任机制，也是防丢失机制。
十：发布标准：核心用例"在保修期内"，其余允许方差
Linear 的发布哲学：核心 hero 用例（建 ticket、管 ticket、建 PR）必须做到 rock solid，相当于"在保修期内"；其余功能允许一定方差，因为这是这类工具的天然属性，先把最常用的三条路径做稳，再谈扩展。
加上一条工程细节：Linear 还让 Agent 自动报告它做不到的功能，团队把它转成 issue，形成一条持续流入的新能力需求流，自改进靠的不是感觉，而是 Agent 自己上报能力缺口。
AI 速览
