Linear 发布技术博客《我们如何构建 Linear Agent》：以边界工程替代脚本化，Agent 落地的一手经验

事件与背景

2026 年 8 月 10 日，Linear 发布技术博客《How we built Linear Agent》，由 Matthijs Wolting 撰写，系统分享 Linear Agent 的工程方法论。文章的核心判断是：好的软件工程通常意味着缩小可能结果的区间，让相同动作可靠地产出相同结果，而 AI 反转了这一逻辑——Linear Agent 的价值恰恰在于做团队未预期的工作，因此不能用固定脚本约束。

关键事实

技术机制或行业解释

Linear Agent 的边界工程包含五个层次：第一，系统提示词聚焦少量基础原则——沟通风格（自然而不企业腔）、硬性边界（不评论敏感话题、不擅自扩大请求范围）、产品专属概念解释（理解 Linear 的领域分类法）、默认意见（短 prompt 下何时推断意图、何时反问）；第二，工具设计决定 Agent 能做什么；第三，Agent 对 Linear 的模型认知决定它如何理解用户请求；第四，每次运行的范围划定影响边界；第五，自定义 harness 在底层提供执行约束。这种设计让 Agent 在 Slack 中能接住对话氛围开个得体的玩笑，同时硬性边界确保它不越权。

影响与意义

对企业级 Agent，Linear 提供了可复制的产品化路径：把"Agent 应该多自主"从模糊原则变成可审计的边界清单；对 SaaS 产品，Slack、Loop 等多界面适配展示了 Agent 如何嵌入真实协作场景而非独立聊天框；对工程团队，它回答了"如何既保持 Agent 灵活性又不失控"的核心问题——答案不是更厚的提示词，而是更清晰的分层边界。

风险边界

Linear 的方法论基于其产品领域（项目管理），跨领域复用需要重新设计边界；系统提示词边界的有效性依赖持续维护，产品迭代可能引入新的越权路径；文章未披露 Agent 的模型选型、失败率与成本数据；"在 Slack 里接住氛围开玩笑"的弹性行为在不同企业文化下的接受度不一。

后续观察

关注 Linear Agent 是否开放更多技术细节（模型、评测、harness 实现）；对比其他 SaaS（Notion、Figma 等）的 Agent 构建方法，提炼共性边界模式；观察"边界工程"是否成为企业 Agent 开发的主流方法论；关注边界清单可审计性是否催生 Agent 治理与合规工具。