过去几个月，我作为产品经理在大量试用和拆解AI产品的过程中，明显感到智能体的开发方式在变化。

此前更多是“拼功能、写路由”的过程型智能体：把操作打包成一个个工具，按流程走完就算交付。

但在实测使用Claude Code实现之后，我的感受是：更合理的范式是“Agent原生”（Agent-Native）

明确结果、交给智能体循环执行直到达成，开发者提供的是原子能力和透明环境，而不是预设流程。

这套方法最近被Dan Shipper与Claude联合发布的《Agent-Native Architecture》系统化阐述

我把过往试用中能落地的部分，结合产品视角做了一次整理。

为什么Claude Code值得关注？

因为它不只是“能写代码”的工具，而是能重新定义智能体的构建方式框架

我在本地用了Claude Code做了几件事：

重构一个旧侧项目的代码结构、整理书摘、生成周报并分配下周优先级。

这些任务并不需要我预先写流程，更多是写清楚结果描述、提供工具权限以及文件空间，智能体就能循环执行、持续迭代把事情完成。

一个“好的编程智能体”在具备合适的工具、上下文和文件接口后，也能自然成为“好的通用智能体”。

Agent原生的五个原则

对等性（Parity）
核心要求：用户在UI能做的所有操作，智能体都能用工具完成。
我在项目中用“列表/读取/增删改”四类工具覆盖UI功能并做自检：随机挑一个UI动作，看智能体是否能完成同样的事。如果不行，我会补工具或调整权限。这是基础条件，缺失时后续能力都会受限。

粒度（Granularity）
工具是原子能力；功能是智能体循环执行后的结果。
实践中我将“生成周报”拆成原子工具：list_files、read_file、write_file、schedule_update，然后用提示词描述结果，让智能体循环、检查是否达成。变更行为时，我优先改提示词和上下文，而不是重构代码。

可组合性（Composability）
有了原子工具和对等性，通过改写提示词就能产出新功能。
例：我给智能体一个新提示词“回顾本周修改文件，按截止日期与未完成项生成三条下周优先级”，不需要新代码，智能体就能组合现有工具完成。

涌现能力（Emergent Capability）
智能体能解决你没有预先设计的任务，失败时暴露差距。
我用开放式请求测试（如“整理研究笔记并按主题归档”），如果能完成，说明原子工具与对等性足够；失败时根据模式补领域工具或调整提示词，避免把判断都写进代码。

自我改进（Self-improvement）
通过上下文累积与提示词优化改进，而不是发版代码。
我将用户偏好与会话状态写入可读文件（如preferences.md、context.md），跨设备共享；调优化时通过更新系统提示或个人提示文件，而不是改动应用逻辑。

让智能体的工作可见、可审阅、可携带

在Agent原生架构里，文件比API更贴合智能体与用户的协作。

实际体验里，文件接口提供了几方面的确定性：

• 智能体对文件操作天然熟悉（读写、移动、目录管理）。
• 用户可见与可编辑，避免黑盒，便于复盘与纠错。
• 数据便携、易备份，跨设备（如iCloud）同步简单。
• 目录即自文档化，结构比数据库查询更直观。

一个可复用的目录结构示例（精简版）：

Documents/
├── AgentLogs/              # 调试日志
│   └── {sessionId}.md
├── AgentCheckpoints/       # 中断检查点
│   └── {sessionId}.json
└── Workspace/              # 用户工作区
    ├── notes/
    └── projects/

我用一个context.md在会话开始注入信息（用户偏好、已有资源、近期活动与基本指南），会话内智能体持续更新它，达到了“便携工作记忆”的效果。

移动端

机会：

文件系统可用，智能体的基础能力在移动端同样适配。

丰富的设备上下文（健康数据、位置、照片、日历），为场景增强提供空间。

本地应用独立演化；通过iCloud共享同一文件系统，无需额外服务器即可跨设备看到智能体输出。

挑战：

智能体任务可能需要数十秒到数分钟，移动系统会后台挂起或终止应用。

需要检查点与恢复机制、有限后台执行策略、本地与云端的分工设计。

我在iOS模拟中采用了检查点策略：应用进入后台、工具调用完成、长操作定时都写入检查点；恢复时扫描有效检查点并从中断处继续。核心结构如下（简化）：

{
  "agentType": "research",
  "messages": [...],
  "iterationCount": 7,
  "customState": { "currentTask": "summarize" },
  "timestamp": "2026-01-01T00:00:00Z"
}

经验：长任务建议在每次工具结果后落盘，后台时间窗口要明确（如iOS给到的短时执行），同时规划何者本地、何者云端。

动态能力

在有外部API（如HealthKit、GraphQL）且能力会随时间新增的系统里，我更倾向于“动态发现”：

• list_available_types() → 返回类型列表
• read_data(type) → 读取任一可用类型

相比为每个数据类型写单独工具，这种原子化让智能体在你未预期的新类型出现时也能访问到。

注意需要配合权限策略与审计日志，避免过度开放。

让智能体的行为可控且可见

共享工作空间
用户与智能体在同一数据空间操作（notes、projects、preferences.md），用户能检查和覆盖智能体的改动；只有在安全或关键数据保护场景使用沙盒。

明确完成信号
不用启发式判断完成。工具返回值应包含是否继续或完成的标记。示例语义：success → 继续、error → 继续（可重试）、complete → 停止循环。

模型层级选择
不同任务使用不同模型能力层级：研究/分析用更强推理；聊天用较快模型；简单分类与批量处理用高吞吐模型。避免“一把尺子量所有任务”。

智能体到UI的即时通信
任何动作都要可见（思考、工具调用、结果、文本响应、状态变化）。在我的项目里，隐藏操作会让用户误判失败；可见进度反而提升信任与容错。

产品方法论

• 简单入口：基础请求“零学习成本”即可见效。
• 可发现的深度：用户深入使用时能暴露更多能力，不做强行引导。
• 模式沉淀：观察用户真实请求，把高频成功/失败模式提炼为领域工具或模板提示词，而不是先假设需求再实现。

我的做法：先提供完整CRUD和基础文件接口，收集日志与请求，按出现频率迭代领域工具与提示模板，避免过早设计复杂流程。

成功检查清单

• 架构层面：对等性、粒度、可组合性、涌现能力、通过提示词改行为。
• 实现层面：系统提示包含资源与能力；共享数据空间；实时UI反馈；实体CRUD完整；动态能力发现；明确完成信号。
• 产品层面：渐进式披露；允许高级用法扩展；基于用户请求做需求发现；风险与可逆性匹配的批准机制。
• 移动端：检查点/恢复；云优先存储（本地回退）；后台执行策略。

终极测试

描述一个你领域内但未特定实现的结果，交给智能体。

它能用现有原子工具在循环中完成吗？

如果能，说明架构足够Agent原生；如果不能，通常是对等性不足、粒度偏大或上下文注入不充分。

小结与建议

就产品与实现层面的体验来看，Claude Code不只是“编程助手”，更像是在推动“Agent原生”的构建范式：文件作为接口、原子工具组合、明确完成信号和上下文累积，是我认为最可复用的四个基石。它们让智能体从“执行预设流程”转向“为结果负责”。

适合尝试的团队与场景：

• 已有明确用户操作集（UI）的应用，愿意把同等能力开放给智能体。
• 数据以文件/目录组织更自然的场景（知识库、项目资料、研究笔记）。
• 需要跨设备、可见可审的协作方式，且能接受基于日志的迭代。

后续我会把这套方法在具体任务上拆解（代码库重构、资料整理、周报生成、移动端长任务处理等），再给出更细的提示词与工具设计示例。如果你也在用Agent原生方式做产品，欢迎交流，我会持续把观察到的高频模式沉淀成可直接复用的清单。