这家团队于 2026 年 8 月 10 日公开了 How we built Linear Agent，把智能体能力边界的设计方法完整摆上台面：精简系统提示词、工具即约束、run scope 限定、skill 渐进披露。这套一手竞品方法论，恰好补上企业 AI Agent 平台搭建最常缺的一课——不是让智能体更聪明，而是先把它关进一个可控的笼子里。
Agent 边界三要素：系统提示词、工具数量与 run scope
官方博客里说得很直接：大多数软件追求行为一致，AI 反过来——价值恰恰来自做你没预想过的事。所以他们没有给智能体写死一条执行路径，而是定义它能在其中自主行动的边界，画在系统提示词、工具设计、产品模型和 run scope 四处。
系统提示词只聚焦一小撮基础：沟通风格、硬边界（敏感话题不表态、不未经确认扩大用户请求范围）、产品特有概念的解释、以及默认使用意见（何时推断意图、何时提问澄清）。提示词保持高层，行为才留得出空间。
工具设计的原则是「约束编码进工具，而不是写进提示词」。参数易懂、让无效操作难以执行，类似好的代码抽象——直觉上该做的事不需要解释。这是多数企业在 Agent 平台搭建里最容易忽略的一层。编排层的取舍，可对照我们拆解的企业自建智能体编排层的 4 个架构决策。
| 边界要素 | 传统脚本做法 | 该团队做法 |
|---|---|---|
| 系统提示词 | 把规则和背景全塞进去 | 只放沟通风格、硬边界、产品概念、默认判断 |
| 工具数量 | 能给的都给，SDK/CLI/API 直连 | 浅而多的业务工具，每个绑定一个产品操作 |
| run scope | 一次 run 暴露全部能力 | 每次 run 只加载任务相关的 skill 包 |
权限模型：Agent 能碰什么数据、能执行什么动作的分级
自研的 harness 实现了「条件工具调用审批」：智能体删除当前对话里自己创建的内容无需确认，删除既有 issue 必须确认；大多数评论线程可直接发，但同步到公共仓库的线程要暂停等待。审批逻辑绑定会话上下文，而不是只按工具名做粗粒度规则。
企业 AI Agent 平台搭建建议至少分三级：只读（查询数据、搜索文档）、可变更（创建、修改会话内资源）、危险动作（删除既有数据、对外发布、跨系统写入）。我们见过某金融科技团队给智能体配了全量写权限，一次批量误操作造成 47 万元资损、整改两周。另一家电商团队每次 run 全量加载 200 多个工具，账单三个月涨了 3.2 倍——权限越粗、能力给得越全，兜底越贵。权限与门禁的落地顺序，可参考企业级智能体从 Demo 到生产的五道工程关卡。
skill 渐进披露：按任务复杂度逐步暴露能力
每个 system skill 打包三样东西：基础元数据、一段系统提示词片段、一组工具，代表一套独立能力。run 开始前，智能体从用户提示和调用上下文推断该预加载哪些 skill——从 Slack 项目频道调起来，大概率预载 projects skill。任务展开时再按需加载：起草项目更新，先加载 projects 和 project updates，中途发现要 review 近期 issue 和 PR，再自己加载对应 skill。
这样做的好处是每个线程的上下文保持聚焦，同时整套能力可以持续扩容而不让每次交互都背着越来越长的提示词和工具集。这直接解决了上下文污染与越权两个典型问题。能力包的组织方式，与多智能体编排的 4 层架构互为补充。
技术细节上，动态工具注入要尽量保留模型提供商的 prefix cache——naive 实现会重算已有上下文，成本上涨非常快。
失败兜底：超时、重复与危险动作的强制中断
这家团队在构建时考虑过给智能体直接访问 SDK、CLI 或 GraphQL API，最终放弃：低层原语会显著扩大出错面，长尾请求在无路可走时容易变成越来越推测性的尝试。他们用一部分广度换确定性——智能体偶尔拒绝它无法安全完成的任务，但犯错空间被大幅压缩。
落地到企业平台，至少要做这五件事：
- 每次 run 设 TTL 与最大工具调用次数，超时强制终止
- 写操作幂等化，重复执行不产生副作用
- 危险动作按上下文要求确认，会话内创建的 vs 既有资源分开对待
- 子任务异步化，父线程挂起不占服务端资源
- 失败后回滚到 run 前快照，保留审计日志
自建 vs 采购平台：五维对比与落地清单
| 维度 | 自建 harness | 采购平台 |
|---|---|---|
| 执行控制粒度 | 精细（动态工具注入、条件审批、子智能体挂起） | 依赖厂商路线图，常需 workaround |
| 权限模型 | 按业务上下文自定义 | 内置角色与审批流，深定制受限 |
| 上下文成本 | 可控，可保 prefix cache | 黑盒，成本结构难优化 |
| 失败兜底 | TTL/幂等/回滚全自主 | 平台级兜底，业务级规则受限 |
| 演进成本 | 开发与维护人力投入高 | 上手快，随厂商升级自动获益 |
落地建议分五步：先盘点核心场景与数据模型复杂度；再明确权限边界与审批矩阵；随后定义 skill 能力包目录，按任务意图渐进暴露；设定 run 超时与幂等规则；最后小范围灰度并盯可观测指标。灰度阶段的算力与基础设施预算，可参考2026 下半年基础设施选型框架。
如果团队缺人手把这类 harness 从零搭起来，可以找优码云聊 /contact，或者先看 /cases 里的同类交付案例，避免踩我们见过的坑。
常见问题
AI Agent 平台搭建时，系统提示词应该写多长？
参考官方博客的做法：精简，只放沟通风格、硬边界、产品概念、默认判断四类基础。复杂约束不要写进提示词，编码进工具设计，让无效操作本身难以执行。
skill 渐进披露和普通工具列表有什么区别？
普通工具列表一次全给，上下文膨胀、越权面大。每个 skill 是元数据 + 提示词片段 + 工具集的组合单元，run 前按意图预加载、run 中按需加载，能力可扩容而不污染每次会话。
自建 Agent harness 和直接用 LangGraph 这类框架差别大吗？
这家公司选自建，因为动态工具注入、条件审批、子智能体挂起这些编排行为在通用框架里要么不支持、要么做 workaround。中小团队可以先框架 + 约束层起步，等场景复杂再迁移。同类平台选型，也可对照 Kitesurf 浏览器自动化的工程取舍（AI Agent 平台搭建：企业网页自动化怎么选）。
权限分级怎么落地才不拖慢业务？
至少分只读、可变更、危险动作三级；审批逻辑绑定会话上下文（会话内创建的 vs 既有资源），而不是按工具名一刀切。绝大多数操作应默认放行，只卡危险动作。
什么信号说明 Agent 边界设计失败？
三个典型信号：长尾任务开始不断推测性尝试、越权操作无确认直接执行、上下文膨胀导致单次 run 成本失控。出现任意一个都建议先收窄 run scope 再谈能力增强。
参考
- 官方博客：How we built Linear Agent（2026-08-10）
- 产品 Changelog：Introducing Linear Agent（2026-03-24）