目录

最近看 AI Agent、Claude Code、Codex、Agent Eval、Dynamic Workflows 这些方向时，我发现一个越来越值得关注的词：

Agent Native。

它不像 Agent Loop 那样已经比较容易解释，也不像 Agent Eval 那样有明确的评测流程。Agent Native 更像是一个正在形成中的架构概念。

但我觉得它非常值得写。

因为它指向一个更大的问题：

AI Agent 时代的软件，不能只是给旧系统加一个聊天框。

过去我们说一个软件支持 AI，往往是这样的：

原来的软件 + 一个 AI 助手入口

比如：

CRM 里加一个聊天框
文档系统里加一个总结按钮
项目管理软件里加一个 AI 问答窗口
代码平台里加一个 Copilot

这当然有用，但它还不是 Agent Native。

真正的 Agent Native，不是让 Agent 站在软件外面模拟人类点击按钮，而是让软件从架构上允许 Agent 安全、可控、可追踪地完成任务。

一句话说：

Agent Native 是为 AI Agent 重新设计的软件架构，而不是在旧软件上贴一个 AI 功能。

一、为什么要讨论 Agent Native？

前面我们已经讨论过几个 Agent 相关概念：

Agent Loop：Agent 如何循环执行任务
Dynamic Workflows：Agent 如何根据任务选择流程
Agent Eval：如何评估 Agent 是否可靠

这些概念关注的是 Agent 本身。

但 Agent 真正进入实际业务时，会遇到另一个问题：

软件系统准备好让 Agent 使用了吗？

很多现有软件是为人设计的。

它默认用户会：

看页面
点按钮
填表单
等待加载
读弹窗
判断结果
手动确认

但 Agent 使用软件时，方式不一样。

Agent 更适合：

理解目标
调用动作
读取结构化状态
执行任务
查看结果
根据反馈继续
留下完整轨迹
必要时请求用户确认

如果软件只提供给人看的 UI，而没有清晰的动作接口、权限系统、状态结构和审计机制，那么 Agent 就只能像人一样“看屏幕、点按钮”。

这会带来很多问题：

不稳定
难追踪
难授权
难回滚
难评测
难治理

所以，Agent Native 的核心问题不是：

我的软件有没有 AI？

而是：

我的软件是否适合 Agent 安全地完成任务？

二、Agent Native 不是一个已经完全定型的标准

先说明一个边界。

Agent Native 现在还不是一个像 HTTP、REST、OAuth 那样成熟稳定的技术标准。

它更像一个正在形成中的架构方向。

最近一些前沿文章已经开始使用这个词。比如 Builder.io 的《Agent-Native: The Next Architecture for Software》把 Agent-native 应用描述为：人类和 AI Agent 可以通过共享动作、数据、权限和上下文来操作同一个产品。

Every 的 Agent-native architectures 也强调，Agent-native 应用会通过积累上下文、改进 prompt 和用户自定义持续变好。

还有更大的趋势，比如 Microsoft 在 Build 2026 期间讨论 agent-first 设备和平台，Gen Digital / Norton 推出面向 AI Agent 通信和治理的 VPN for Agents。这些都说明：软件、设备、安全基础设施，正在开始为 Agent 重新设计。

所以我们在写 Agent Native 时，不应该把它讲成“行业已经完全统一的标准术语”。

更准确的说法是：

Agent Native 是 AI Agent 时代正在形成的一种软件设计思想：应用从一开始就考虑人类和 Agent 共同使用，而不是把 Agent 当成事后外挂。

三、从 AI-enabled 到 AI-native，再到 Agent-native

为了理解 Agent Native，先区分三个概念。

AI-enabled
AI-native
Agent-native

它们听起来很像，但层级不同。

1. AI-enabled：软件里加了 AI 功能

AI-enabled 是最常见的形式。

比如：

文档软件里加一个“总结全文”
客服系统里加一个“智能回复”
图片工具里加一个“AI 抠图”
CRM 里加一个“AI 生成客户摘要”

它的特点是：

原来的产品结构基本不变
AI 是一个附加能力
用户仍然主要通过传统 UI 操作
AI 通常只完成局部任务

这类产品有价值，但 AI 不是系统核心。

它像是：

旧软件 + AI 按钮

2. AI-native：AI 成为产品核心能力

AI-native 更进一步。

它不是简单加一个 AI 功能，而是产品核心体验围绕 AI 构建。

比如：

AI 写作工具
AI 绘图工具
AI 代码生成工具
AI 搜索引擎
AI 视频生成平台

这些产品如果没有 AI，就不成立。

它的特点是：

AI 是核心生产力
用户主要通过自然语言或多模态输入表达意图
软件输出的是 AI 生成或 AI 辅助的结果

但 AI-native 也不一定是 Agent-native。

因为很多 AI-native 应用仍然是一次性生成：

输入 prompt -> 模型生成 -> 用户拿结果

它未必能持续行动、调用工具、管理状态、处理权限、回滚结果。

3. Agent-native：软件为 Agent 行动而设计

Agent-native 更进一步。

它关注的不是 AI 能不能生成内容，而是：

Agent 能不能在软件里安全地行动？

Agent-native 应用通常具备：

清晰的动作接口
结构化状态
权限系统
上下文持久化
审计日志
人机协作界面
可验证结果
可回滚机制

它不只是让 AI 生成一段文字，而是允许 Agent 完成真实任务。

比如：

不是：帮我写一段客户跟进建议
而是：帮我筛选本周高优先级客户，生成跟进计划，创建任务，提醒销售确认

这就不只是 AI 生成了，而是 Agent 在系统里执行了一个业务流程。

四、为什么“加一个聊天框”不够？

很多软件接入 AI 的第一反应是：

在右下角加一个聊天框。

用户可以问：

帮我总结这个页面
帮我生成一段话
帮我找一下数据
帮我解释这个报表

这当然有用。

但对于 Agent 来说，聊天框只是入口，不是架构。

如果软件底层没有为 Agent 准备好动作和状态，Agent 会非常受限。

问题一：Agent 只能“说”，不能“做”

如果聊天框只能生成文本，Agent 最多回答：

你可以点击左侧客户列表，然后筛选成交概率大于 80% 的客户。

但它不能真的帮你完成筛选、创建任务、发送提醒。

这还是聊天机器人，不是 Agent Native。

问题二：Agent 只能模拟点击，容易不稳定

如果系统没有动作接口，Agent 只能像人一样操作页面：

看按钮
点按钮
等加载
读弹窗
继续点

这种方式很脆弱。

页面布局一变，Agent 可能就失效。

按钮文案一改，Agent 可能找不到。

弹窗多一个确认，Agent 可能卡住。

真正的 Agent Native 应用，不应该只依赖“视觉点击”，而应该暴露稳定的动作模型。

比如：

{
  "action": "create_task",
  "parameters": {
    "title": "跟进高意向客户",
    "owner": "sales_001",
    "due_date": "2026-07-01"
  }
}

这比让 Agent 在页面上找按钮稳定得多。

问题三：权限边界不清楚

如果 Agent 和用户共享同一个 UI，却没有清晰权限系统，就会出问题。

例如：

Agent 能不能删除客户？
Agent 能不能修改合同金额？
Agent 能不能发送邮件？
Agent 能不能导出数据？
Agent 能不能访问高权限报表？

如果这些边界不清楚，Agent 很难进入真实业务场景。

Agent Native 应用必须回答：

Agent 是谁？
它代表哪个用户？
它能做什么？
它不能做什么？
哪些动作需要用户确认？
哪些动作必须记录审计？

问题四：没有可追踪性

Agent 做完一件事后，系统必须知道：

它为什么这么做？
调用了哪些工具？
读了哪些数据？
改了哪些状态？
有没有经过用户确认？
结果能不能回滚？

如果只是聊天框，很多过程会消失在对话里。

但真实业务需要审计。

尤其是：

金融
医疗
法律
企业管理
代码变更
数据分析
权限系统

这些领域不能只靠一句“AI 已完成”。

五、Agent Native 的核心定义

我会这样定义 Agent Native：

Agent Native 是一种面向 AI Agent 的软件架构。它让人类和 Agent 可以在同一个应用模型中，基于共享动作、共享数据、共享权限、共享上下文和可追踪记录来完成任务。

这个定义里有几个关键词：

同一个应用模型
共享动作
共享数据
共享权限
共享上下文
可追踪记录

也就是说，人和 Agent 不是两套系统。

不是：

人用正式系统
Agent 用外挂脚本

而是：

人和 Agent 都通过同一套业务模型操作系统

人可以点按钮。
Agent 可以调用 action。
但它们背后操作的是同一套状态、权限和业务规则。

这才是 Agent Native 的关键。

六、Agent Native 应用的七个特征

我认为，一个 Agent Native 应用至少应该具备七个特征：

1. 共享 Action Model
2. 共享状态和上下文
3. 身份、权限和授权
4. 可观察、可追踪、可回放
5. 人和 Agent 可以协同
6. 可评测、可验证、可回滚
7. 应用会随上下文持续变好

下面逐个展开。

七、特征一：共享 Action Model

Action Model 可以理解成应用允许执行的动作集合。

比如一个任务管理系统，可能有这些动作：

create_task
update_task
assign_task
set_due_date
add_comment
mark_done
archive_task

传统软件里，这些动作通常隐藏在按钮、表单、菜单背后。

Agent Native 应用要做的是：把这些动作抽象成稳定、结构化、可调用的接口。

例如：

{
  "action": "assign_task",
  "parameters": {
    "task_id": "task_123",
    "assignee": "user_456"
  }
}

这样，人和 Agent 可以通过不同入口调用同一个动作。

人类入口：点击按钮、拖拽卡片、填写表单
Agent 入口：调用结构化 action

但底层执行同一套业务逻辑。

这很重要。

因为如果人和 Agent 走两套逻辑，就容易出现不一致：

人创建任务会触发通知
Agent 创建任务却不触发通知

人修改金额会写审计日志
Agent 修改金额却没有日志

人删除数据需要确认
Agent 删除数据不需要确认

这会带来严重问题。

Agent Native 要求：

同一个动作，同一套规则。

八、特征二：共享状态和上下文

Agent 要完成任务，必须知道当前系统状态。

比如：

当前用户是谁？
当前项目是什么？
哪些任务已经完成？
哪些数据可以访问？
上次用户偏好是什么？
这个客户最近发生了什么？

如果每次 Agent 都从零开始，它会很低效。

所以 Agent Native 应用需要共享状态和上下文。

上下文可以分几类：

会话上下文：当前对话里发生了什么
任务上下文：这个任务的目标、步骤、结果
用户上下文：用户偏好、权限、历史行为
业务上下文：客户、订单、项目、文档、代码等状态
组织上下文：团队规则、审批流程、安全策略

传统应用通常只关心数据库状态。

Agent Native 应用还要关心：

Agent 需要什么上下文才能正确行动？
哪些上下文可以持久化？
哪些上下文必须隔离？
哪些上下文不能给 Agent？

Every 的 Agent-native architectures 里提到一个重要方向：Agent-native 应用可以通过积累上下文和 prompt 改进持续变好。

这说明 Agent Native 应用不是静态工具，而是会随着使用积累工作记忆。

九、特征三：身份、权限和授权

Agent Native 最关键的问题之一是权限。

因为 Agent 不只是回答，它会行动。

只要 Agent 能行动，就必须有身份和权限。

我们需要知道：

这个 Agent 是谁？
它代表哪个用户？
它能访问哪些数据？
它能执行哪些动作？
哪些动作需要确认？
哪些动作禁止执行？

比如在企业系统里：

销售 Agent 只能访问自己的客户
主管 Agent 可以看团队报表
财务 Agent 可以看付款状态，但不能随意改合同
HR Agent 可以读取候选人资料，但不能导出敏感信息

Agent Native 应用必须把这些规则内建进去。

不能让 Agent 绕过人类权限。

一个好的设计是：

Agent 的权限 <= 被代理用户的权限

也就是说，Agent 不能因为是 AI 就获得额外特权。

另外，高风险动作应该有确认机制：

低风险：自动执行
中风险：执行后通知
高风险：执行前确认
关键风险：禁止自动执行

例如：

自动整理客户列表：低风险
创建待办任务：低风险
发送邮件草稿：中风险
正式发送客户报价：高风险
删除客户数据：关键风险

Agent Native 应用的权限系统，不只是技术问题，也是信任问题。

十、特征四：可观察、可追踪、可回放

Agent 做事必须留下轨迹。

这类轨迹通常叫 trace。

一个完整 trace 应该记录：

用户给了什么目标
Agent 制定了什么计划
调用了哪些 action
读取了哪些数据
每一步返回了什么结果
遇到了哪些错误
是否请求用户确认
最终修改了哪些状态

为什么 trace 很重要？

因为没有 trace，就没有审计。

没有审计，就无法信任。

比如 Agent 修改了一个客户状态：

客户 A 从“普通线索”变成“高优先级线索”

系统应该能回答：

为什么改？
依据是什么？
谁授权？
用到了哪些数据？
能不能恢复？

传统应用可能只记录最后结果。

Agent Native 应用应该记录完整过程。

有些文章会把这类记录称为 receipt，也就是每个状态变化的“凭证”。

这非常适合 Agent Native。

因为 Agent 的每一步动作都应该能被检查、回放和解释。

十一、特征五：人和 Agent 可以协同

Agent Native 不是让 Agent 完全替代人。

更现实的形态是：

人设定目标
Agent 执行过程
人在关键节点确认
Agent 继续推进
人审核最终结果

也就是说，人和 Agent 需要协同。

一个好的 Agent Native 应用，应该支持这种交互：

Agent：我找到了 20 个高意向客户，其中 5 个建议今天跟进。
用户：先处理前三个。
Agent：我已生成跟进任务，要不要同时生成邮件草稿？
用户：可以，但不要自动发送。
Agent：已生成草稿，等待你确认。

这里 Agent 不是简单聊天，而是在产品状态里行动。

它创建任务、生成草稿、等待确认、继续执行。

人和 Agent 共用同一个工作区。

这就是 Agent Native 和普通 AI 助手的区别。

十二、特征六：可评测、可验证、可回滚

Agent Native 应用必须考虑结果验证。

因为 Agent 很可能出错。

它可能：

理解错任务
调用错工具
选择错数据
跳过关键步骤
过度自信
执行了不该执行的动作

所以系统要能验证：

任务是否完成？
结果是否正确？
有没有违反约束？
有没有产生副作用？

在代码场景里，验证可以是：

测试通过
构建通过
Lint 通过
代码审查通过

在 CRM 场景里，验证可以是：

任务是否创建成功
客户是否符合筛选条件
邮件是否经过确认
权限是否合规

在财务场景里，验证可以是：

金额是否一致
审批是否完成
凭证是否存在
日志是否完整

另外还要能回滚。

比如 Agent 批量创建了 50 个任务，但用户发现条件错了。

系统应该能：

显示这 50 个任务是 Agent 创建的
支持批量撤销
保留撤销记录
说明撤销原因

Agent Native 应用不能只追求“能自动做”，还要支持“做错了能恢复”。

十三、特征七：应用会随上下文持续变好

传统软件通常是：

开发者发版 -> 用户使用 -> 开发者再发版

软件能力主要通过代码更新提升。

Agent Native 应用会多一个维度：

上下文积累
Prompt 改进
用户偏好学习
任务历史沉淀
评测反馈优化

比如一个写作 Agent：

第一次不知道你的风格
第二次记住你喜欢短句
第三次知道你不喜欢营销腔
第四次能按照你的公众号结构写

再比如一个项目管理 Agent：

它知道你每周一整理计划
知道哪些任务通常需要提醒
知道你喜欢先处理高风险事项
知道哪些同事负责哪些模块

当然，这里要注意隐私和权限。

持续变好不等于无限记忆。

Agent Native 应用需要让用户控制：

哪些偏好可以保存
哪些上下文可以删除
哪些记忆只在当前项目有效
哪些信息不能进入长期记忆

十四、复杂例子：传统 CRM 如何变成 Agent Native CRM

下面用一个复杂例子说明。

假设我们有一个传统 CRM 系统。

它原本支持：

客户列表
客户详情
销售跟进
合同管理
任务提醒
邮件记录
报表分析

如果只是 AI-enabled，我们可能加一个聊天框：

帮我总结这个客户
帮我写一封跟进邮件
帮我分析本月销售情况

这有用，但还不是 Agent Native。

Agent Native CRM 应该支持更完整的任务。

场景：让 Agent 帮销售准备今日跟进计划

用户说：

帮我找出今天最值得跟进的客户，生成跟进计划，但不要自动发邮件。

Agent Native CRM 应该这样工作。

第一步：理解目标

Agent 识别目标：

任务：生成今日客户跟进计划
约束：不要自动发邮件
对象：当前销售可访问客户
输出：跟进客户列表 + 跟进理由 + 建议动作

第二步：读取结构化数据

Agent 不应该靠看页面截图。

它应该调用系统 action 或 query：

{
  "action": "query_customers",
  "parameters": {
    "owner": "current_user",
    "updated_within_days": 30,
    "stage": ["意向", "报价中", "待决策"]
  }
}

系统返回结构化数据：

{
  "customers": [
    {
      "id": "c_001",
      "name": "A 公司",
      "stage": "报价中",
      "last_contact_days": 6,
      "deal_amount": 120000,
      "risk": "竞品介入"
    }
  ]
}

第三步：根据规则筛选

Agent 使用业务规则：

高金额优先
长期未跟进优先
临近决策时间优先
有竞品风险优先
客户最近有正向互动优先

输出候选：

1. A 公司：报价中，金额高，6 天未跟进，有竞品风险
2. B 公司：本周有采购会议，适合提前确认需求
3. C 公司：上次回复积极，但尚未安排 Demo

第四步：创建任务，但不越权

用户允许生成计划，不允许自动发邮件。

所以 Agent 可以调用：

{
  "action": "create_task",
  "parameters": {
    "customer_id": "c_001",
    "title": "跟进 A 公司报价反馈",
    "due_date": "2026-06-29",
    "owner": "current_user"
  }
}

但不能调用：

{
  "action": "send_email"
}

如果要生成邮件，只能生成草稿：

{
  "action": "create_email_draft",
  "parameters": {
    "customer_id": "c_001",
    "requires_approval": true
  }
}

第五步：留下 trace

系统记录：

用户目标：生成今日跟进计划，不自动发邮件
读取数据：客户列表、最近互动、合同阶段
筛选规则：金额、阶段、未跟进天数、竞品风险
执行动作：创建 3 个任务，生成 2 封邮件草稿
未执行动作：没有发送邮件
用户确认：未请求发送确认

这样管理员和用户都能追踪 Agent 做了什么。

第六步：验证结果

系统可以验证：

创建的任务是否属于当前用户
客户是否都在用户权限范围内
是否没有实际发送邮件
是否所有任务都有客户 ID
是否所有草稿都需要人工确认

这就是 Agent Native CRM。

它不是简单聊天，而是让 Agent 进入 CRM 的业务模型里安全执行。

十五、简单例子：待办事项 App 如何变成 Agent Native

再看一个非常简单的例子。

传统待办事项 App 有这些功能：

新建任务
设置截止日期
标记完成
删除任务
添加标签

如果只是 AI-enabled，可能加一个功能：

AI 帮你生成任务标题。

但 Agent Native 的待办 App 会更进一步。

用户说：

帮我把明天上午要做的三件事排一下优先级。

Agent 可以：

1. 读取明天上午的任务
2. 查看每个任务的截止时间
3. 根据重要程度排序
4. 建议优先级
5. 等用户确认后更新排序

结构化动作可能是：

{
  "action": "update_task_priority",
  "parameters": {
    "task_id": "task_123",
    "priority": "high"
  }
}

但如果用户说：

把所有低优先级任务删掉。

这就是高风险动作。

Agent 应该先确认：

我找到 8 个低优先级任务。删除后不可恢复，是否确认？

这说明即使是简单 App，Agent Native 也需要：

动作接口
状态读取
权限边界
确认机制
执行记录

十六、Agent Native 和 Agent Loop 的关系

Agent Loop 关注的是 Agent 如何做事：

目标 -> 计划 -> 行动 -> 观察 -> 更新 -> 验证 -> 停止

Agent Native 关注的是软件如何支持 Agent 做事。

两者关系可以这样理解：

Agent Loop：Agent 的执行循环
Agent Native：应用给 Agent 提供可执行环境

如果没有 Agent Loop，Agent 不会持续行动。
如果没有 Agent Native，Agent 很难安全稳定地行动。

传统软件里，Agent Loop 可能只能这样：

看页面 -> 猜按钮 -> 点击 -> 观察截图 -> 再猜

Agent Native 软件里，Agent Loop 可以这样：

理解目标 -> 调用 action -> 读取结构化结果 -> 验证状态 -> 继续执行

后者明显更可靠。

所以 Agent Native 可以看作是给 Agent Loop 提供更好的“道路系统”。

十七、Agent Native 和 Agent Eval 的关系

Agent Eval 关注的是：

如何评估 Agent 是否可靠

Agent Native 应用天然更适合 Eval。

因为它有：

结构化 action
结构化状态
完整 trace
权限记录
验证结果
回滚记录

这些都可以进入评测系统。

例如评测一个 CRM Agent：

它是否只访问了授权客户？
它是否正确创建了任务？
它是否没有自动发送邮件？
它是否给出了合理跟进理由？
它是否留下完整操作轨迹？

如果应用不是 Agent Native，这些问题很难自动评估。

因为 Agent 可能只是操作 UI，很多状态不结构化，很多过程不可追踪。

所以：

Agent Native 让 Agent Eval 更容易落地。

反过来，Agent Eval 也能推动 Agent Native 应用持续改进。

十八、开发者如何开始设计 Agent Native 应用？

如果你是开发者，想把一个应用往 Agent Native 方向改，不需要一开始就推倒重来。

可以从五步开始。

第一步：列出核心动作

先不要急着接大模型。

先列出你的应用有哪些核心动作。

例如项目管理工具：

create_project
create_task
assign_task
update_status
add_comment
set_due_date
generate_report

这些动作是 Agent 未来能做事的基础。

第二步：给动作加结构化 schema

每个动作都应该有清晰输入输出。

例如：

{
  "name": "create_task",
  "description": "Create a task in a project",
  "input": {
    "project_id": "string",
    "title": "string",
    "assignee": "string",
    "due_date": "date",
    "priority": "low | medium | high"
  },
  "output": {
    "task_id": "string",
    "status": "created"
  }
}

这会让 Agent 更容易调用，也更容易验证。

第三步：接入权限系统

每个 action 都要检查权限。

比如：

用户能不能创建这个项目下的任务？
用户能不能指派给这个人？
用户能不能设置高优先级？
这个动作是否需要确认？

Agent 调用 action 时，不能绕过权限。

第四步：记录 trace

每次 Agent 调用 action，都记录：

谁发起
为什么发起
调用了什么
参数是什么
结果是什么
是否成功
是否用户确认

这一步一开始可能看起来麻烦，但后面非常有价值。

因为它支持：

审计
调试
回滚
评测
持续改进

第五步：设计人机协作界面

Agent Native 不一定只有聊天框。

可以有：

任务队列
审批面板
Agent 操作记录
建议卡片
待确认动作列表
回滚按钮
差异对比视图

比如 Agent 想批量修改 20 条记录，界面可以展示：

将要修改什么
为什么修改
风险是什么
是否确认
是否只执行部分

这比一个聊天框可靠得多。

十九、Agent Native 的风险和边界

Agent Native 很有前景，但也有风险。

1. 权限扩大风险

Agent 能做事后，权限问题会被放大。

一个错误动作可能影响很多数据。

所以必须有：

最小权限
动作分级
敏感操作确认
权限审计

2. 自动化误操作

Agent 可能理解错用户意图。

比如用户说：

清理一下无效客户。

Agent 可能误以为要删除客户。

更安全的做法是：

先筛选
再解释
再生成建议
最后等待确认

3. 责任边界不清楚

如果 Agent 做错了，责任是谁的？

用户？
开发者？
模型提供商？
企业？
Agent 平台？

Agent Native 应用需要在产品层面设计责任边界。

至少要做到：

高风险动作有确认
关键结果有记录
重要操作可回滚
用户知道 Agent 做了什么

4. 上下文泄露

Agent 需要上下文，但上下文也可能包含敏感信息。

例如：

客户数据
财务数据
内部文档
个人隐私
代码密钥
商业计划

所以 Agent Native 应用必须控制上下文访问范围。

不是所有信息都应该进入 Agent 上下文。

5. 过度自动化

不是所有事情都应该自动化。

有些任务需要人类判断。

比如：

裁员决策
医疗建议
法律意见
重大合同审批
财务付款
生产环境变更

Agent Native 不是让 Agent 接管一切，而是让 Agent 在合适边界内行动。

二十、未来趋势：软件可能从 App-first 走向 Agent-first

过去的软件是 App-first。

用户打开一个 App，然后自己完成任务：

打开 CRM -> 找客户 -> 筛选 -> 写跟进 -> 建任务 -> 发邮件

Agent 时代可能变成 Goal-first 或 Agent-first。

用户先说目标：

帮我准备今天的客户跟进。

然后 Agent 在多个系统里完成：

CRM 查客户
日历查空闲时间
邮件生成草稿
任务系统创建提醒
文档系统附上资料

这意味着软件的入口可能变化。

过去入口是：

App 图标
页面导航
按钮菜单

未来入口可能是：

目标
任务
Agent
工作流

这不是说传统 UI 会消失。

而是软件要同时服务两类使用者：

人类用户
AI Agent

这就是 Agent Native 的长期意义。

二十一、总结

Agent Native 是 AI Agent 时代非常值得关注的架构方向。

它不是简单地给软件加一个聊天框。

它真正关心的是：

软件是否从架构上支持 Agent 安全、可控、可追踪地完成任务？

一个 Agent Native 应用，至少应该具备：

共享 Action Model
共享状态和上下文
身份、权限和授权
可观察、可追踪、可回放
人和 Agent 可以协同
可评测、可验证、可回滚
应用会随上下文持续变好

如果说：

Agent Loop 解决 Agent 怎么做事
Dynamic Workflows 解决 Agent 怎么选择流程
Agent Eval 解决 Agent 怎么证明可靠

那么：

Agent Native 解决的是：软件系统如何为 Agent 重新设计。

我认为未来真正有竞争力的软件，不只是“用了 AI”，也不只是“有一个 AI 助手”。

而是它的底层架构已经准备好让 Agent 进入真实工作流：

能理解目标
能调用动作
能读取状态
能遵守权限
能留下轨迹
能验证结果
能请求确认
能回滚错误
能持续改进

一句话总结：

Agent Native 不是让 Agent 模拟人类使用旧软件，而是让软件原生支持 Agent 成为可靠的行动者。

这可能是 AI Agent 真正落地之前，软件架构必须跨过的一道门槛。

参考资料

  • Builder.io：《Agent-Native: The Next Architecture for Software》
    https://www.builder.io/blog/agent-native-architecture

  • Builder.io：《How to build agent-native applications and what not to do》
    https://www.builder.io/blog/agent-native-apps

  • Builder.io Agent Native GitHub 项目
    https://github.com/BuilderIO/agent-native

  • Every：《Agent-native Architectures》
    https://every.to/guides/agent-native

  • Every：《Agent-native Architectures: How to Build Apps After the End of Code》
    https://every.to/chain-of-thought/agent-native-architectures-how-to-build-apps-after-the-end-of-code

  • Microsoft：《Composing a new platform for agent-first devices》
    https://commandline.microsoft.com/project-solara-build-2026/

  • Microsoft WorkLab：《2026 Work Trend Index: Agents, human agency, and the opportunity for every organization》
    https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization

  • Gen Digital：《Gen Accelerates Agentic Security and Privacy for the AI Era》
    https://newsroom.gendigital.com/2026-04-30-Gen-Accelerates-Agentic-Security-and-Privacy-for-the-AI-Era

# 人工智能
Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

cover

我用 NVIDIA SkillSpector 纯静态扫了一遍 GitHub 最火的 agent skills：能挖出多少注入？0 个

avatar 龙虾开发者社区
cover

周榜换血九成，Agent Skills 星数翻倍

avatar 龙虾开发者社区

写给 TypeScript 工程师的 OpenClaw.NET 上手指南：用你熟悉的 TS 思维，跑起一个生产级 AI Agent

读代码层：TS 和 C# 本来就是「远房亲戚」——asyncawait??、接口、泛型、严格空检查，你的心智模型几乎无缝平移。真正要适应的只有两件事：类型是具名而非结构化的（多一句显式声明），以及 NativeAOT 下的「禁反射」约束。写扩展层：你甚至可以不怎么碰 C#——Node.js 插件桥意味着你的 TypeScript 插件就是一等公民，而且能在生产 aot 车道跑。内核给你 .NET

avatar 龙虾开发者社区