从个人提效，到 AI 原生团队

很多团队开始用 AI 的样子都差不多：少数人已经把 AI 用成了个人杠杆，少数工程师把 Agent 接进工具链，管理层看到了几个像未来一样的 demo，于是大家期待这种能力自然扩散到整家公司。

它通常不会自然扩散。

从“AI 帮个人变快”到“我们是 AI 原生团队”，中间差的不是一周写了多少 prompt，不是有多少流程接了 AI 插件，甚至不只是模型够不够强。模型当然重要，更强的模型会不断打开新的工作面。但在公司内部，真正决定差距的，往往是工作系统本身。

Agent 能不能理解一项任务，理解到足以开始行动？它能不能拿到正确系统里的信息，同时碰不到不该碰的东西？它能不能连续工作几十分钟甚至几个小时，还不丢掉主线？人能不能看懂它到底做了什么？组织能不能从每一次运行里学到东西，让下一次更容易？

如果要给一个可操作的定义，我会这样说：

AI 原生团队的工作，已经变得能被 Agent 读懂，可以被安全委派，并且会通过 Agent 留下的轨迹持续改进。

这和“给每个人开通 AI 工具”不是同一个目标。AI 原生团队建设的是一套新的工作模型：人和 Agent 共享目标、上下文、工具、权限、证据和责任。终点不是一个无所不知的超级 Agent，而是很多个有边界的 Agent，在工作本来发生的地方，完成一块块真实任务。

AI 原生不是活跃度，而是操作模型

过去两年，很多团队衡量 AI 落地时看的是活跃度：开通了多少账号，发了多少 prompt，用了多少 copilot，消耗了多少 token，有多少工作流接入了 AI。这些数字不是完全没用，但它们很浅。

一个公司可以有很高的 AI 活跃度，但真实流程几乎没变：人让 AI 起草、总结、检索、改代码；复制到另一个系统里；发现上下文不够，再手动补一轮；最后仍然由人把结果推进到下一步。

这是 AI 辅助工作。它有价值，但还不是 AI 原生工作。

更清楚的趋势是：Agent 正在从个人助手和局部 copilot，进入任务系统、IDE、工单队列、文档、会议、客户流程和后台运营。OpenAI 关于 Agent 工作方式的研究，把这种变化描述为从短对话走向可以委派的长周期任务。Microsoft 对企业 Agent 的判断也很接近：真正改变业务的不是 AI 本身，而是 AI 周围那套系统。

这里还有一个变化很容易被低估：AI 原生团队不是只让一个 Agent 接住一个人的请求，而是开始编排多个 Agent 并行工作。一个人可以同时发起代码修改、数据清洗、竞品整理、客户访谈归纳和内部工具搭建。团队真正获得的不是“回答更快”，而是一种可调度的智能劳动力。

这个判断很重要。AI 原生团队不是在旧流程上撒一层 AI，而是重做流程，让 Agent 成为一等参与者：

工作被写进任务系统，而不只存在人的脑子里
相关上下文找得到，也有明确权限边界
工具提供清楚、可审计的操作面
Agent 身份被限定在具体工作域里
输出进入决策前能被验证
运行轨迹、评估和记忆会改进下一次执行

“原生”这个词不能只当修饰语。移动原生产品不是把桌面网页硬塞进小屏幕；云原生系统也不是把旧服务器架构原样搬进别人的机房。AI 原生工作也不是给旧工作流外挂一层个人助手。

它是围绕“把任务委派给会使用工具的智能系统”重新设计工作。

所以，判断一个团队是不是 AI 原生，可以先看五个问题：

任务是不是能被 Agent 直接接住，而不是靠人临时解释半天？
上下文是不是来自团队系统，而不是来自某个高手的复制粘贴？
权限是不是按工作域设计，而不是粗暴继承某个人的全部权限？
验证是不是嵌在流程里，而不是最后凭感觉看一眼？
一次执行之后，团队的模板、记忆、工具或评估有没有变得更好？

如果这五件事没有发生，AI 只是让个人变快；如果它们持续发生，团队的工作方式才真的开始变。

上下文是第一层共享基础设施

Anthropic 对 context engineering 的定义很适合放在这里。Prompt engineering 关心的是怎样把指令写好；context engineering 关心的是模型推理时看见的整套信息：系统提示、工具、MCP、外部数据、检索到的文档、文件、记忆和历史消息。

这个区别非常关键。Agent 不是只回答一次。它会循环工作：查看状态、调用工具、读取文件、写下笔记、产出中间结果，然后继续判断下一步做什么。每一步都会产生新的信息，而这些信息不一定都应该进入下一轮模型调用。

很多公司的 AI 落地卡在这里，不是因为个人不会用 AI，而是因为上下文还停留在个人手艺阶段。某个高手知道该复制哪段背景、该补哪句约束、该告诉模型哪些历史决策。这能提高个人效率，却很难变成团队能力。

到了团队层面，上下文必须从“谁比较会问”变成共享基础设施。

可以换一个问题问：如果今天有一位靠谱的新同事加入这个项目，他需要知道什么，才敢负责任地行动？

Agent 需要的东西很接近：

项目的目标
当前进展
术语、口径和指标定义
关键决策的来龙去脉
哪些系统才是事实来源
可以调用哪些工具
哪些边界不能越过

如果这些信息只在某个人脑子里，Agent 就会反复追问。信息在 Slack 里但找不到，它就会漏掉。信息虽然给了，但埋在一大堆噪声里，它可能抓错重点。信息读得到，但这个任务本来不该读，那就成了安全问题。

所以真正要做的，不是急着接上所有数据源，而是让组织在合适的粒度上变得可读。

这意味着文档要有清楚的负责人，会议纪要要区分背景、决策、负责人和未决问题，工单要写验收标准，而不是只写一个模糊意图。看板要有指标定义，runbook 要说明什么时候继续、什么时候停下、什么时候找人审批。

AI 之前，这些只是好的文档习惯。Agent 进来之后，它们变成了生产基础设施。

上下文越多，不代表上下文越好

长上下文窗口很容易诱惑团队把所有东西都塞进去：完整仓库、所有频道、全部会议纪要、客户历史、看板导出。表面上这是“给足背景”，实际上常常只是把筛选责任推给模型。

Chroma 的 Context Rot 研究给了一个很好的提醒：输入越长，模型并不会均匀地使用所有上下文；即使在受控任务里，表现也会随着上下文膨胀变得不稳定。

这不是说上下文只能短。有些任务确实需要大量背景。真正的结论是：每一段上下文都必须有理由进入窗口。

更好的目标，是给 Agent 一组最小但高信号的初始上下文，同时保留按需继续获取信息的能力。Anthropic 把这类做法称为 just-in-time：初始上下文里不塞完整语料，而是放文件路径、链接、已保存查询、工具名、ID 和索引，让 Agent 运行时再去取真正相关的部分。

这对安全也更健康。数据只在真正需要的那一刻、以更小的粒度进入模型窗口，并且仍然处在权限边界里。效果和安全在这里并不冲突：少一点噪声，也少一点不必要的权限。

下次 Agent 出错，先别急着怪模型，可以沿着上下文链路查一遍：

检查项	要问的问题	常见表现
授权	它被允许看这份信息吗？	它跳过步骤，或者说没有权限
可达性	它真的拿得到信息吗？	它开始猜，或者说没有数据
检索	它能找到正确的那一小段吗？	它读了很多，却漏掉关键细节
可理解性	结构本身有没有传递语义？	它用错文件、指标或业务口径
工具匹配	它有合适的操作面吗？	分析得很好，但事情落不了地

“可理解性”特别容易被低估。Agent 会读结构。tests/test_utils.py 和 src/core_logic/test_utils.py 文件名一样，但含义完全不同。launch-q3-pricing 这样的频道名，比 random-project-2 有用得多。一个叫 active_enterprise_trials_with_owner 的保存查询，也比一张看板截图更适合 Agent 使用。

AI 原生团队不是指望 Agent 通灵。它们会把工作环境变得更容易理解。

权限域是团队 AI 的基本单位

个人 AI 可以继承某个人的权限。团队 AI 没这么简单。

安全之所以要讲这么多，是因为一旦 Agent 能真正行动，权限就不再是后台配置，而是团队设计的一部分。

一个共享频道里，可能有好几个人都会让 Agent 做事；任务可能在人下线之后继续跑；Agent 可能同时需要用数仓、GitHub、工单系统和文档库。这个时候，“让它代理某个用户”很快就不够用了。

Claude Tag 的 agent identity 是一个具体参考。在多人协作场景里，Claude 不是替某个用户行动，而是以自己的身份行动：管理员在工作区层面定义访问范围，再按频道覆盖；私有频道有独立身份；记忆和访问都遵守这些边界，私有频道里学到的东西不会自动跑到更大的工作区里。

NIST 在 2026 年关于软件 Agent 身份和授权的工作，也指向同一个方向。只要 Agent 开始跨系统自主行动，组织就需要识别、授权、审计和不可抵赖这些能力，而这些能力不能默认每一步都有一个人在亲手点击。

这里可以抽象出一个更重要的产品单元：权限域。

权限域可以是一个频道、一个项目空间、一个客户小组、一条业务线，或者一个具体工作流。它定义的是：

哪个 Agent 身份在这里工作
哪些人可以调用它
它能访问哪些工具和数据
它能不能写入
记忆存在哪里
留下哪些日志
哪些动作需要审批

关键在于，这条边界不只是协作边界。它同时也是上下文边界、记忆边界、工具边界和安全边界。

所以设计 AI 原生团队时，问题不该是“我们要把整家公司交给哪个 Agent”，而该是“哪些工作域值得拥有自己的 Agent 身份”。

产品发布域可以访问发布计划、路线图、用户研究、分析看板和只读工单；法务域可以访问合同模板和审查流程，但不需要工程仓库；客服升级域可以访问客户工单、账户信息和 runbook，但不该碰薪酬、融资或战略文档。

可读不等于敞开。可读的意思是：对的 Agent，在对的权限域里，为了对的目的读得到。

权限要管住读、写、记和说

很多团队一谈权限，想的都是“读”。Agent 能不能看这份文档？能不能查这张表？

这只是第一层。

Agent 还会写产出、做摘要、存记忆、调用工具、安排后续任务，并把信息从这一次运行带到下一次。一个可靠的权限模型，至少要管住四个动作：

动作	风险	设计规则
读	看见了不该看的数据	不该访问的东西，就不要挂载、不要暴露
写	过大范围地改变状态	写入要限域、可回滚、留日志，必要时单独审批
记	敏感上下文跨会话留存	记忆必须留在权限域内
说	输出泄露或聚合了敏感信息	产出的敏感级别继承输入里的最高级别

后两项最容易漏。

一段保密讨论的摘要，仍然是保密内容。十条看起来都“没问题”的信息拼在一起，可能就足够还原一个还没公开的决策。NOTES.md、项目记忆、定时任务的状态文件，都可能变成持久上下文；如果提示注入写进这些地方，之后每次启动都会重新加载。

最稳妥的规则很简单：产出和记忆的权限，不能低于它们所依据的材料。除非有人明确、主动地降级。

环境边界比模型承诺更可靠

安全不能只靠一句提示词。告诉 Agent“不要访问秘密”，不如让秘密根本不在它够得到的地方。

Anthropic 关于 containment 的复盘里有几个很实际的提醒。人工审批有用，但审批不是沙箱；他们观察到用户批准了大约 93% 的权限弹窗。出口白名单有用，但它授予的是能力，不只是目的地。工具连接器有用，但连接器可信，不等于它返回的内容也可信。

更耐用的原则是：环境优先，模型其次。

环境层负责硬边界：沙箱或 VM、文件挂载方式、只读和可写目录、默认拒绝的网络出口、凭据代理、可撤销 token、隔离执行环境。模型层仍然重要，系统提示、分类器、探针和训练都能降低坏行为的概率。但概率性的防线应该放在确定性的边界里面，而不是取代边界。

这也是为什么隔离强度要匹配使用者和工作流。能看懂 shell 命令的工程师，和在 Teams 或 Jira 里审批卡片的业务同事，适合的监督方式不是同一种。一个低风险草稿 Agent，和一个能改账单、薪酬、生产基础设施或客户权益的 Agent，也不该用同一套控制。

团队部署时，有三条规则最好一开始就写清楚：

凭据和密钥不要放在 Agent 能读到的文件或上下文里。
不要为了省事，让同一个 Agent 身份跨多个敏感级别。
不要用一句 prompt 指令，代替真正的硬边界。

验证是工作流的一部分

AI 原生团队不是简单地委派更多任务，而是把验证做得更好。

很多乐观的 AI 落地会卡在这里。Agent 可以产出比团队来得及检查的更多内容。如果验证仍然完全靠人工，组织得到的只是更快的草稿，而不是更快被接受的结果。

解决办法不是把人从判断里拿掉，而是把验证嵌进工作流：

执行前有验收标准
执行中有测试、eval 或检查清单
工具调用和文件改动有日志
重要结论有引用或证据
人只在有意义的关口审批
复盘会更新下一次的指令、模板或评估

工程团队已经在 CI、测试、代码评审和可观测性里熟悉了一部分模式。AI 原生工作只是把这种思想扩展到更多职能。客服 Agent 应该说明它用了哪条政策和哪些客户事实；财务 Agent 应该留下报表背后的查询轨迹；市场 Agent 应该说明草稿依据了哪些品牌规则和来源材料；招聘 Agent 应该区分候选人的事实、模型推断和人的最终判断。

关键指标不是 Agent 产出了多少，而是有多少产出带着足够证据落地了，返工少，责任清楚。

人负责为什么和要不要

AI 原生不是把人拿掉，而是把人放到更对的位置。

人在高频、碎片化、带压力的弹窗审批里表现并不好。人更擅长的是设目标、划边界、解释取舍，以及决定什么东西应该成为团队的规则。

公司里最有价值的上下文，很多仍然是隐性的：路线图为什么改了，上次迁移踩过什么坑，哪个客户绝不能碰，这个季度到底要速度还是稳定。只要这些判断还只在人的脑子里，Agent 就只能在浅层上下文里行动。

所以人的角色会变：

执行前：定义目标、约束、红线和成功标准
执行中：只在少数不可逆或高风险关口审批
执行后：复盘结果，决定什么值得固化进团队的可复用上下文

落到具体任务，可以看两根轴：动作是否可逆，结果是否容易验证。

任务类型	默认分工
可逆，且容易验证	交给 Agent 做
可逆，但难验证	Agent 先做，人抽样复核
不可逆，但容易验证	Agent 准备，人到关口确认
不可逆，且难验证	人来决定，Agent 提供证据和选项

Agent 动手，不代表责任消失。授予自主权的人或职能，仍然要对结果负责。前提是全程看得见：谁调用了 Agent，它读了什么，调用了哪些工具，写了什么，改了哪些记忆，哪些检查通过了，最后是谁签字。

AI 原生团队里，人不该继续做人工中转站。人更像是上下文的生产者、边界的设计者，以及判断的负责人。

交付物会变成下一次的上下文

最大的变化之一，是交付物不再只是交付物。

一份好的会议纪要，不只是给人看的记录，也可以成为 Agent 直接消费的任务说明。决策日志不是行政负担，而是未来 Agent 需要的“为什么”。Runbook 不只是支持文档，也可以沉淀成 Agent Skill。

Anthropic 的 Agent Skills 是一个很好的模式。一个 skill 本质上是一个文件夹，里面有 SKILL.md，也可以有脚本、参考资料、模板和素材。关键设计是 progressive disclosure：Agent 先只看 skill 的名字和描述；任务相关时再读完整说明；真正需要时才加载附属文件。

组织知识也应该长成这种形状。不要试图把整本公司手册塞进每个上下文窗口。把流程、案例、脚本和领域知识拆成可以按需加载的单元，让 Agent 在需要时再拿。

这些单元最好从真实工作之后沉淀，而不是一开始凭空设计。做完一个任务后，回头问：

哪些背景是人反复手动补的？
哪些错误重复出现？
哪些工具调用让 Agent 困惑？
哪些决策应该变成模板？
哪些检查应该写成脚本，而不是让模型每次重新推理？
哪些事实应该进入记忆，哪些应该被忘掉？

答案就可以变成 skill、runbook、模板、eval、保存查询或结构化笔记。这样，每一次成功的 Agent 运行，都会让下一次更容易。

90 天落地路径

AI 原生团队应该从窄处开始。上来就做大平台，很多时候只是把学习推迟了。

第 1-30 天：先证明它能做有用的事。 选一两个高频、痛感强、验收标准清楚的流程，比如周报归因、客服升级分流、需求澄清、发布说明、客户访谈整理、发票复核。只用低敏或中敏数据，工具尽量窄，能只读就先只读。重点是留下完整轨迹：Agent 缺了哪些上下文，哪些地方需要人补，什么证据让结果可以被接受。

第 31-60 天：把模式沉淀下来。 复盘这些轨迹。反复补的上下文，写成模板、笔记、skill、工具描述、保存查询，或者改进文档结构。给代表性任务加简单 eval。删掉职责重叠的工具。定义哪些动作需要审批，哪些动作可以直接跑。

第 61-90 天：变成团队系统。 从个人会话迁到权限域。定义 Agent 身份、记忆边界、审计日志、审批关口和环境控制。每次只扩一个权限，并且用日志证明为什么需要扩。开始衡量被接受的结果，而不只是活跃度。

衡量这件事，也不要只看“这周有多少人用了 AI”。更值得看的指标是：

一次通过率：多少任务不需要人返工
补上下文次数：一个任务里，人平均要补几次背景
交付周期：从提出请求到结果被接受，花了多久
评估覆盖率：多少重复流程有明确检查
沉淀率：这个月新增或改进了多少 skill、模板、查询、runbook
扩权质量：新增了哪些授权，每一项基于什么日志证据
单位结果成本：每个被接受结果消耗了多少 token、运行时间和人工复核成本

真正的问题不是“AI 活跃度高不高”，而是组织是不是越来越容易被 Agent 读懂，越来越适合让 Agent 安全地行动，也越来越快地把 Agent 的工作转化成被接受的结果。

真正的转变

个人提效只是起点。成为 AI 原生团队，是组织设计问题。

模型只是系统的一部分。团队真正的优势来自模型周围：可读的工作记录，设计清楚的工具，明确的 Agent 身份，隔离的记忆，硬的环境边界，有用的日志，能抓住失败的评估，以及负责“为什么”和“要不要”的人。

终点不是一个无所不知的 Agent，而是一支团队里有很多个 Agent，能在各自边界里并行完成有用的工作。因为这家公司已经把知识变得清楚，把权限变得精确，把验证循环变成真实流程。

这就是从“AI 帮个人变快”，走到“AI 可以安全参与我们的工作方式”。

本文综合了 Anthropic 关于 context engineering、Agent Skills、containment、Claude Tag 和 agent identity 的公开文章，也参考了 OpenAI 关于 Agent 工作方式的 2026 年研究、Microsoft 关于企业 Agent 系统的文章、Atlassian 关于 Jira 中 Agent 工作流的描述、Chroma 的 Context Rot 研究，以及 NIST 关于 AI Agent 身份、授权和安全的公开材料。

参考来源

Effective context engineering for AI agents — Anthropic Engineering, Sep 29, 2025
Equipping agents for the real world with Agent Skills — Anthropic Engineering, Oct 16, 2025
How we contain Claude across products — Anthropic Engineering, May 25, 2026
Introducing Claude Tag 和 Agent identity in Claude Tag — Anthropic, Jun 2026
How agents are transforming work — OpenAI Economic Research, Jun 25, 2026
AI alone won’t change your business. The system running it will. — Microsoft, Jun 2, 2026
Introducing Cursor in Jira — Atlassian, May 20, 2026
Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma Research, Jul 14, 2025
AI Agent Standards Initiative、Identity and Authority of Software Agents、Summary Analysis of Responses to the RFI Regarding Security Considerations for AI Agents — NIST, 2026