1. 我为什么从 AI-first 转向“agent-native”思维先说个背景。去年我在团队里负责把一个老牌业务系统改造成 AI 应用最初我们按行业里“AI-first”的思路走把大模型接入现有流程给用户加了一个对话入口把原来散落在各个后台接口里的能力用自然语言包装了一下。跑了一段时间后我发现这套东西看起来像 AI 应用实际上是一个非常昂贵且不太稳定的接口转发器。用户问一句模型调一堆 API返回一段文字然后就结束了。用户觉得不够聪明产品觉得能力没发挥出来工程那边整天在处理超时和上下文爆掉的问题。后来我去复盘了很多同类项目包括我们内部另一个做得还不错的实验产品慢慢意识到问题出在根上我们一直在把 AI 当成一个附加层而没有把 AI 智能体当成系统的主角。这个区别其实就是“agent-native”和过去所有所谓智能化改造的本质区别。”agent-native“这个词最近在技术圈里讨论很多我也看了不少文章但多数都在讲哲学概念讲“让智能体成为系统的一等公民”之类的大道理。我这篇想聊点具体的基于我这一年在两个项目里的实际落地经验拆解一下真正的 agent-native 系统应该是什么样包含哪些核心模块以及我在实操中踩过哪些坑。无论你是在做 AI 应用架构选型还是想把现有系统改造成智能体驱动这篇都可以给你一些能直接用的参考。简单说agent-native 不是一个技术名词更接近一种架构立场。它意味着从数据库表结构设计、接口协议定义、权限模型、监控体系到前端交互逻辑每一个环节都默认“操作主体是一个自主决策的 AI 智能体”而不是默认“操作主体是一个坐在屏幕前的人类用户”。这个转变看起来只是视角变化实际上会颠覆掉非常多你习以为常的设计习惯。2. Agent-native 和“套壳加智能体”的本质区别四个关键维度我在很多技术讨论里发现一个常见误解大家觉得我的系统接入了大模型做了工具调用 Function Call让模型能查询订单、能发邮件这就是 agent-native 了。这个认知差得很远。为了把问题说清楚我整理了一个对比维度表你可以拿它来评估你自己的系统目前处于哪个阶段评估维度传统系统 / 接入式 AIAgent-native 系统操作主体假设人类用户通过界面操作AI 是辅助层AI 智能体自主决策并执行人类是监督者数据模型设计按业务流程和人类操作习惯建表按智能体执行单元、任务状态、上下文建表接口协议为前端 UI 设计一次调用返回完整视图数据为智能体设计接口语义化、自描述、可组合权限模型按账号/角色区分考虑一个人能干什么按任务和会话级授权考虑一个智能体在什么条件下能干什么可观测性记录用户点击、页面请求、操作日志记录智能体思维轨迹、工具调用链、状态变更事件状态管理会话状态在服务端集中管理短生命周期任务状态分布式持久化长生命周期可恢复可重放容错设计接口幂等、重试、事务回滚智能体执行失败后能自我纠正、动态调整步骤性能指标QPS、响应时间、可用性任务完成率、工具调用成功率、决策质量、用户干预率拿权限模型举个例子。传统系统里登录用户点击“删除订单”按钮后端检查这个账号是否有删除权限有就执行。agent-native 系统里一个智能体在一个任务执行过程中可能连续调用多个 API它需要访问数据的范围取决于当前任务上下文而不是取决于它属于哪个“角色”。前者的权限判断是静态的、基于身份的后者的权限判断是动态的、基于任务上下文的。如果还沿用传统权限模型智能体就会频繁撞权限墙然后进入一个无法自主解脱的死循环。再比如接口设计。传统接口面向 UI通常会返回聚合好的、直接用于展示的数据结构字段名可能都带 UI 含义。agent-native 的接口面向的是智能体的决策循环模型需要理解这个接口是干什么的、输入输出是什么语义、调用后有什么副作用。接口如果不自描述模型就疯狂猜测如果接口是粗粒度的智能体就无法组合出灵活的操作序列。这些差异会直接反映在任务成功率上而不是代码能不能跑通这种表面问题上。我在实践中发现一个非常有效的检验方法如果你把界面整个隐藏掉只给智能体开放同一套 API你的业务还能不能完整跑下来如果答案是不能那说明你的系统还是以人为主设计的AI 只是站在人的肩膀上操作那套为人类准备的界面和接口而已。3. 从“能用”到“好用”关键模块和设计取舍真正把 agent-native 落到工程上你会发现它不是某一个组件的技术选型而是一整套基础能力的重新设计。我按一个系统从下到上的分层逐个拆一下在每个层面我经历了什么、改了什么、为什么这么改。3.1 运行时与执行引擎给智能体一个稳定的“身体”很多第一次做 agent 系统的人会把智能体的核心逻辑写在一个大的循环里读模型输出、解析工具调用、执行工具、把结果喂回去。这个循环本身不难难的是你在这个循环外面要建立多少配套设施。我的第一个坑就是把这个循环当成了整个系统的全部没有去想“如果这个循环中途崩了怎么办”“如果这个循环卡住了怎么办”“如果有多个智能体在同时跑怎么办”。后来我意识到agent-native 需要一个真正意义上的运行时类似于 Java 应用需要 JVM、业务系统需要应用服务器智能体也需要一个承载它执行过程的基础平台。这个运行时至少要负责这几件事第一执行调度。一个复杂任务往往不是单次推理就能完成的它会拆成多个子任务有些子任务要调用外部工具有些子任务要等待用户确认有些子任务可能要走一个长达数小时甚至数天的异步流程。这种调度和传统后台 Job 调度完全不同因为子任务的划分不是预先定义好的而是智能体在运行过程中动态产生的。所以运行时需要支持动态流程编排而不是静态的工作流引擎。第二超时与重试策略。模型调用有超时工具调用有超时你要决定在每一层分别设置多长的超时时间以及超时之后是重试、降级还是终止任务。我见过很多同学把所有超时都设成一样的值结果短调用被长调用拖死长调用被短超时误杀。这里没有银弹我的经验是模型调用给 60 秒工具调用给 15 秒整体任务不设硬超时但设置预警超过 5 分钟没人确认就触发通知。第三断点恢复。智能体执行到第 7 步模型服务商那边炸了或者你的服务发布重启了这个任务是不是要从头再来agent-native 系统里绝对不是任务状态要支持持久化快照重启之后能从最近的断点恢复。这一步听起来简单但对状态管理的设计要求非常高后面我会单独讲。第四并发隔离。同一个智能体系统可能同时在跑几十上百个任务任务之间不能互相污染。尤其要注意共享内存和共享状态的问题我见过因为用了一个全局变量存储任务上下文导致串号的惨案两个用户的任务互相读到了对方的数据这个事故如果在生产环境会是非常严重的安全事件。3.2 工具层接口语义化程度决定了智能体的能力上限智能体要完成任务最终靠的还是调用工具。工具层在 agent-native 架构里的地位比大部分人想象的高得多。最初的实现里我们就是把现有系统的 REST API 直接暴露给模型然后告诉模型每个接口的参数和用途。跑下来发现效果很差原因有几个第一API 路径充满内部命名习惯。比如/api/v2/order/queryByUser人类工程师一看就知道是查订单模型也能猜个大概但猜不等于确定不确定就会导致调用参数填错。第二参数结构过于面向 UI。有些字段是前端展示用的枚举值有些字段需要组合才能表达完整语义模型经常填出一些在业务上不存在的组合。第三现有接口缺少对“副作用”的描述。模型调用接口时不知道这个操作会改什么数据、需要什么前置条件也就无法判断调用的风险。后来我们做了两件比较关键的事。第一件事给所有暴露给智能体的工具写一种类似“工具说明书”的元数据用尽量标准的协议来承载而不是各自为政的注释。我们最后选了 MCPModel Context Protocol这个方向它的好处是把工具发现、工具调用、工具返回完整地规范化了智能体可以发现“这个服务器上有哪些工具”并且知道每个工具精确的输入输出结构。这比我们之前用 JSON Schema 手拼要规整得多也顺手解决了多端复用的问题。第二件事我们把粗粒度的接口改造成细粒度的能力单元。原来有一个“提交订单”的大接口内部串了校验库存、计算价格、锁库存、生成订单、清空购物车五个环节这个接口给人类用非常方便一次调用搞定但给智能体用就成了一个巨大的黑盒。一旦智能体想要在提交之前校验一下库存、或者在价格计算环节换个优惠策略它做不到。拆成五个可独立调用的能力单元之后智能体就能像搭积木一样灵活组合出各种新流程。这带来的一个额外收益就是很多以前需要写死流程的变体需求现在智能体自己就能通过组合完成产品经理少写了很多 if-else。这里有一个代价拆细了之后一次任务可能需要调用更多次工具带来更多的延迟和更多的失败概率。这个平衡要自己把握我在项目里是只对高频和关键链路做拆分低频辅助能力保持原样避免过度设计。3.3 状态管理不要把智能体的记忆塞进数据库表这是整个 agent-native 系统里最容易被低估、也最容易出事故的部分。记录一次对话的上下文和记录一个智能体的任务状态是两种难度完全不同的事情。对话上下文相对简单——把用户说了什么、模型回了什么存下来就行很多团队用 Redis 或者简单地存一个大字符串就搞定了。任务状态不然。一个复杂任务在执行过程中会经历多个阶段每个阶段有不同的子目标每个子目标有自己的输入输出任务过程中会产生中间结果、工具返回的原始数据、推理过程摘要还有用户中途提出的修正意见。这些信息要组织起来既要支持智能体在下一步决策时快速获取相关上下文也要支持人类在事后复盘时看到完整的执行轨迹。我们第一版用传统业务表结构来存任务状态给每个阶段建一张表结果发现智能体不是按固定的阶段走流程的它会跳过、合并、回退状态机会被它走出各种我们想都没想过的路径。强行用状态机约束智能体又回到传统 BPM 的老路上去了。后来我们换成了事件溯源Event Sourcing的思路。每个任务不再有一个“当前状态”而是记录一串不可变的事件流当前状态是通过重放事件流计算出来的“投影”。智能体每做一个决策、每完成一次工具调用、每收到一条修正反馈都产生一个新事件追加到事件流里。这样做的好处非常明显任何时间点发生了什么完全可追溯如果任务要回退不用硬改数据而是回放到某个事件之前的投影多个微服务之间同步任务状态广播事件而不需要共享数据库。代价是事件流的重放和投影计算本身也有工程成本我们做了一个事件存储和一个简单的投影缓存层避免每次读状态都全量重放。如果你团队里有 DDD 背景的人对这套应该很熟如果没有强烈建议先去了解事件溯源的基本模式再决定要不要上这个方案。我是觉得对于 agent 这种天然非线性的执行主体事件溯源几乎是唯一干净的状态管理方案。另外一个和状态相关的问题是记忆分层。智能体执行任务需要不同粒度的记忆长期稳定的事实比如用户的偏好、业务规则、本次任务的中间过程刚才算了什么、结论是什么、以及当前步骤的短期工作记忆当前正在处理的数据。我们一开始把这三类记忆全放在同一个存储里结果上下文检索时经常混在一起模型会被几周前的偏好带偏当前决策。后来分成三个存储层次长期记忆进向量库按需检索任务中间过程进事件存储按任务 ID 精确读取短期工作记忆只保留在运行时内存里配合 prompt 优化正确率提升非常明显。3.4 可观测性从看日志到看“执行轨迹”做传统服务的时候我们监控的是 QPS、错误率、响应时间打日志靠 log.info 和 log.error出了问题基本能靠调用链追踪定位。到了 agent-native 系统这套完全不够用因为错误的形态变了。传统系统出错是明确的异常被抛出错误信息里包含定位线索。agent-native 系统出错往往是任务最后完成了但用户完全不满意因为智能体绕了很多弯路、做了很多无用调用甚至调用了一系列工具之后得了错误结论但代码层面没有任何异常报出来。这种“静默的坏结果”是最难排查的。我建议在 agent-native 系统里建立三个层次的可观测性。基础层是传统的日志和指标记录模型调用耗时、工具调用成功率、Token 消耗量用于发现问题的大致方向。中间层是 trace但这里的 trace 和分布式链路追踪不是一个概念。trace 要覆盖的是智能体的决策轨迹它看到了什么上下文、做了什么推理、下一步为什么选择调用这个工具而不是那个、工具返回了什么、模型如何解读这个返回。这个轨迹要完整串起来才能回答“为什么这个任务跑偏了”这类问题。最高层是运行记录重放。就像游戏中录像回放一样把一次任务的完整执行过程记录下来包括模型输入输出、工具输入输出、中间状态变更然后可以在调试器里逐步回放随时查看每一步智能体的内部状态。这个能力极大地加速了我排查那些隐蔽问题的速度目前实现方式是把事件流里的事件和对应的 LLM 调用记录关联存到一个专门的回放存储中前端做一个时间轴界面就能像看视频一样看任务执行过程。我见过有些团队每跑一次任务就打印一份完整日志出了披露问题人肉翻日志效率极低。agent-native 系统的排查工作几乎注定要面对大量的上下文信息没有一个结构化、可检索、可回放的观测平台你根本抓不到问题本质。3.5 安全与权限让智能体在边界内自由行动我在前文说过agent-native 的权限模型和传统基于角色的权限模型完全不同。这里我想展开讲一下实际落地的经验因为这个环节做不好智能体要么什么都干不了要么什么都敢干。我们的方案是三层授权。第一层是工具级权限。智能体可以调用哪些工具在创建它的配置里就定义好。一个只做数据查询的智能体就不应该拥有发起支付的工具。这个级别的粒度比较粗但是第一道防线作用是限制攻击面。第二层是任务级授权。每个任务启动时系统会根据任务类型和发起人身份生成一个临时的权限凭证。这个凭证包含当前任务允许访问的数据范围、允许调用的工具列表、允许操作的目标 ID 范围。智能体每次调用工具时运行时都会检查凭证是否覆盖这次调用不覆盖就直接拒绝并把拒绝事件写入轨迹。第三层是人机协同确认。对高风险操作比如删除数据、发送对外消息、执行资金变动我们强制要求智能体先发起确认请求由人类用户确认之后才真正执行。这个操作在 agent 架构里不能实现成简单的“二次弹窗”因为智能体不是一个等待用户点击按钮的前端应用。我们把它实现成一种外部确认事件智能体在执行到高风险操作时暂停发出确认请求事件进入等待状态收到确认事件后继续执行。这本质上是一种异步的人工审批机制好处是智能体不会阻塞其他任务坏处是要管理等待状态的超时和处理用户长时间不确认的兜底策略。三层授权都覆盖完之后我们的才能说可以放心让智能体在无人盯守的情况下执行一些任务。即便如此我还是建议把高风险操作的最小化做得更严格一些能不给智能体的权限尽量不给宁可让它频繁停下来请求确认也别让它拥有过多“隐形权力”。4. 实战上线一次真实迁移的完整记录与关键决策理论讲得再多也得看实际操作。我挑一个我们做过的真实项目来走一遍完整流程把一个内部客服工单分配系统改造成 agent-native 架构。这个系统业务不太复杂但覆盖了前面讲到的绝大部分设计要点非常适合当样板。4.1 改造前的问题定位和方案选型原有系统是标准的 MVC 结构工单提交后按预设规则自动分配给对应客服客服处理完填写处理结果系统记录整个流程。我们发现的问题分配规则写死在代码里遇到复杂情况比如客户情绪不好、问题跨多个部门、同一客户多个工单关联规则就失灵工单处理过程有很多步骤依赖客服的判断系统只提供信息登记功能没有任何辅助决策能力。我们定义的目标形态用户提交工单后一个智能体负责理解工单内容、查询历史信息、按需拆分子任务、分配或升级、跟踪整个处理过程、在需要人工介入时发出请求完成之后生成处理总结。在这个目标下我们做了几个关键选型运行时框架没有用市场上现有的 agent 平台而是基于自己的核心库封装了一层运行时因为我们需要和现有内部系统深度集成现成平台很难支持我们那些有点古怪的内部 API模型选了支持较长上下文窗口的商用模型配合我们自己的记忆分层方案这个组合在实际测试中表现最稳定工具接口按前面说的 MCP 方向自建了一套工具服务器状态管理直接纳入我们已有的事件溯源基础设施没有另起炉灶。选型过程有个值得分享的原则不要为了用新概念而引入新东西。agent-native 是一种架构视角不是需要一套全新技术栈。能复用现有基础设施就复用比如事件溯源、权限中心、监控平台这些都可以在不同项目里共享。真正必须新做的只有运行时、工具层和特殊的可观测性组件这三样。4.2 关键是先梳理“能力地图”而不是先写代码很多团队落地 agent 系统犯的最大错误是上来就写智能体的提示词。一个连自己手头有哪些能力、哪些数据都不知道的智能体提示词写得再漂亮也撑不起复杂的业务。我们第一步做的是梳理能力地图。把所有和工单相关的后端能力列出来逐个判断它们适不适合暴露给智能体、需不需要拆分、参数要不要重新设计。整个过程大概花了一周半产出是一张完整的工具清单每项工具包含名称、描述、输入 Schema、输出 Schema、副作用说明、所需权限项、关联数据实体。这张能力地图看起来就是一份文档实际上它决定了后续所有开发的边界。有了它你才能知道智能体在理想情况下能做什么再回来判断业务流程要覆盖到什么程度。我们也通过这份地图发现了几个以前根本没人注意的死角比如查工单历史时能力分散在三个系统里没有一个统一入口比如某个“修改优先级”的能力没有在日志里记录修改人这在 agent 场景下是不符合可追溯要求的。梳理完能力地图之后我们才开始写智能体的编排逻辑和提示词。提示词里面除了角色设定、任务目标、约束条件之外最重要的一段是“能力使用指南”它不是简单罗列工具清单而是把常用任务的最佳路径写出来比如收到一个投诉工单建议的步骤是读工单详情、查客户历史、查关联工单、判断严重程度、必要时发确认请求。把人类专家的工作经验注入到提示词里能显著减少智能体在早期版本里出现的无头苍蝇式探索。4.3 联调阶段的模拟环境和回归集和智能体系统联调比传统前后端联调要复杂得多因为你没法预设智能体每一步会调用什么接口。我们做了一个专门为 agent 设计的模拟环境核心是一个工具调用回放器把生产环境里采集到的一批真实工单历史数据导入沙箱环境然后把所有依赖外部系统的工具调用都改造成从预置数据集中返回固定格式的模拟响应。这样每一次测试都能完全确定地回放相同的环境和数据智能体的行为差异就能被准确地归因到代码或提示词变更上。我们还积累了一个回归测试集大概 80 个典型工单场景涵盖正常流程、异常流程、边界情况。每次改动之后跑一遍回归集记录任务完成率、完成质量和步骤偏离度。千万别小看这个回归集agent 系统的输出具有不确定性没有这个基线你根本无法判断一次改动是变好了还是变坏了。说到评估我再提醒一句任务完成率只是一部分还要关注“过程质量”。有的智能体把任务完成了但是用了 30 次工具调用中间反复试错这种情况在用户侧感知就是“很慢、很笨”。我们在回归集里额外记录了每次任务的工具调用次数和用户干预次数作为过程质量的辅助指标推动后续优化。4.4 从灰度到全量的几个关键控制点上线没有搞一刀切我们分了三个阶段。第一阶段是内部试用我们让三个客服组试用新的智能体辅助模式但智能体只做“建议”不直接执行任何写操作。它给客服提供处理思路、推荐下一步动作、自动收集相关信息由客服决定是否采纳。这个阶段价值很大因为它用极低的成本验证了智能体的判断质量也让我们从一线客服那里收集到了不少改进意见。第二阶段是半自动模式选定一部分低风险工单类别让智能体自动处理全流程但每一步操作仍然记录日志并有随时中断的开关。这个阶段暴露了很多我们在联调阶段没发现的细节问题比如某些工具在真实网络环境下会偶尔超时智能体在超时后的处理策略不好比如自动分配方案在个别场景触及了组织规则里的灰色地带需要补充规则。第三阶段才是全量自动经过前两个阶段将近六周的打磨智能体已经能稳定处理约七成的工单剩余的三成会触发人工干预事件由客服介入处理。上线之后我们持续追踪了两周整体满意度和处理时长都比老系统有可量化的改善。看到对比数据那一刻我才确信这条 agent-native 的改造路线是走对了。5. 常见问题与排查技巧实录这里把我在项目实施过程中遇到频率最高、也最有代表性的问题列出来每个都附上分析和解决方案供你对照排查。5.1 智能体陷入工具调用循环怎么办症状任务一直不结束模型一遍又一遍调用同一个或一组工具每次都得到相同或类似的返回值却无法得出最终结论。日志显示 Token 消耗在飞速增加用户侧感知就是“这个东西卡住了”。原因分析最常见的原因是模型的决策空间里缺少终止条件。它没有足够的信息判断“解决问题了”或者“这条路径走不通了应该放弃”。另一个常见原因是工具返回值格式不清晰模型读了返回值之后无法提取出对决策有意义的结论只好反复尝试。解决方案给工具返回值增加一个专门给模型看的“决策摘要”字段把业务层面有意义的结论直接提炼出来。比如查询库存的工具返回原始数据列表之外加一句“库存充足可正常发货”或“SKU-123 库存不足仅剩 2 件”。这个摘要字段对模型决策的帮助远比你想象的大。同时在提示词里明确写“任务完成条件”和“放弃条件”并且设置工具调用次数上限超过上限强制终止并触发升级人工处理。上线初期我们甚至有意识地接受“误终止”因为中止一个跑偏的任务远比让它烧着 Token 空转要健康。5.2 上下文爆掉和关键信息丢失症状任务稍微复杂一点模型就开始遗忘早期步骤的关键信息比如用户最初提到的特殊要求、前面工具调用返回的一个重要数字。更大的问题是把上下文塞满之后模型的推理质量明显下降。原因分析这是记忆分层没做好。把所有信息都塞进上下文窗口等于没有记忆。早期步骤的信息如果不具备持久价值就不应该一直占据上下文空间而有些信息又必须在任务全程保持可访问那么就要设计专门的记忆读写机制。解决方案我们最终落实的记忆分层是这样工作的短期工作记忆只保留当前步骤所需的最小信息每次模型调用之前运行时自动从三个层面组装上下文——与当前任务相关的历史事件摘要、用户明确标注“记住”的长期事实、当前步骤的输入输出。关键信息的持久化不是靠模型自己总结而是运行时在事件发生时就提取要保留的字段存入结构化存储里。这个机制跑通之后上下文占用基本平稳不再随着任务推进无限膨胀。5.3 工具调用成功率不低但任务完成率上不去症状从指标看工具调用成功率 90% 以上模型也没有明显报错但是任务最终完成率只有五成。用户在事后复盘时觉得智能体“做了很多事但没有真正解决问题”。原因分析这个问题的本质是工具调用和目标达成之间存在落差。工具调用成功只代表接口正常返回了不代表智能体拿到了它需要的、可以支撑决策的信息。比如查客户历史信息接口返回了 200但返回的列表少了几个关键字段的解析模型没意识到数据不完整就基于残缺信息继续往下走了。解决方案设计和打磨工具时要把“这个工具返回的数据是否足够模型完成下一步决策”当作核心标准。我们为此在工具层做了一件事增加工具返回的完整性自校验部分关键工具在返回数据时附带数据置信度说明当模型判断置信度不足时它会主动要求补充查询而不是硬着头皮往下走。另外一个辅助手段是提升任务目标拆解的质量。有些场景下任务完成率低不是工具问题而是模型对目标的拆解和人类预期不一致它把“处理工单”完成成了“查询了工单信息”没有做出任何处置动作。我们在提示词里增加了“任务验收标准”小节定义清楚什么程度算完成效果立竿见影。5.4 安全事件智能体越权访问了不该访问的数据症状在审计日志中发现一个被指派处理普通咨询任务的智能体在某次执行过程中调用了获取客户支付配置信息的工具这个操作与当前任务完全无关。虽然没有造成实际数据泄露但这是一个实打实的越权行为。原因分析和解决方案这个问题发生在我们第三层授权机制上线之前的版本智能体只要有工具调用权限就能调用。后来我们落实了任务级授权每次任务启动生成临时凭证规定工具调用必须匹配当前任务的允许范围。事件发生之后我们还加了一条规则工具服务器在收到调用请求时不仅校验凭证是否覆盖工具本身还校验目标数据对象的类型和 ID 范围双保险杜绝越权访问。给读者的建议是不要等出了事故再补安全控制agent-native 系统的权限设计应该从第一天就按三层授权模型来做尤其是那些可以对外发送消息、修改核心数据、触发资金动作的工具宁可保守也不要放开。6. 最后说说团队协作和工程文化的转变技术层面聊完了我还想补充一个容易被忽略但几乎决定项目成败的维度agent-native 不只是一个技术架构它还会深刻影响团队怎么协作。传统开发流程里产品经理定义需求、后端开发提供 API、前端开发做界面、测试人员写用例每个角色都有明确分工。agent-native 项目里最难以定义岗位的是“智能体本身算谁的代码”。我们的实践是专门成立了一个跨职能小组里面有后端工程师、Prompt 工程师这个角色目前还比较新但有价值、业务专家、测试工程师。这个小组共同维护“智能体能力库”——包括工具描述、提示词表现、评估集、性能基准。任何改动都要过这个小组以一体化验证避免出现“后端改了接口、Prompt 工程师不知道、智能体突然开始调错参数”这种典型的割裂事故。另外一个经验是团队需要对不确定性有更高的容忍度。传统项目交付通常有明确的验收标准agent-native 项目则更像是“训练一个模型让它学会做一件复杂的事”你只能不断逼近目标不太可能一次性做到完美。我会建议团队建立一套持续评估和快速迭代的机制每次改动都跑回归集、对比指标、复盘失败案例把它当作一套产品在运营而不是当作一个工程项目在交付。我个人这套方法落地后最大的感慨是agent-native 的价值不是把界面换成对话框那么简单。当你真的把智能体当作系统的主角来设计很多旧体系里默认为人类操作习惯而设计的机制都需要重新考量包括接口、权限、状态、监控、组织协作。这个过程没有捷径但你踩过的每一个坑都会转化为系统长板。如果你正准备启动类似的改造项目我建议你从能力地图梳理开始把一个最小的垂直业务场景完整趟一遍积累经验之后再横向推广。这个路径我从结果回头看应该是效率最高、风险最小的走法。