SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场agent-native-architecture

agent-native-architecture

智能体与模型

查看项目

更新于 10-15 14:09

技能介绍

用途

Agent-Native Architecture 是一套用于构建「智能体原生（agent-native）」应用的方法论与技能，来源为 everyinc/compound-engineering-plugin。其核心主张是：把智能体当作应用的一等公民来设计软件，让功能不再只是开发者预先写好的代码，而是由具备工具的智能体在循环中不断尝试、直至达成目标的结果。

该技能适用于设计自主智能体、创建 MCP 工具、实现自我修改等场景，并可用于从零规划新的智能体原生系统、把现有代码重构得更「智能体原生」，以及测试智能体原生应用的能力与对等性。

核心原则

资料给出五条核心原则：

  1. 对等性（Parity）：用户能通过 UI 完成的操作，智能体都应能通过工具达成。这是基础原则。添加任何 UI 能力时都应自问：智能体能否达成同样的结果？若不能，就补充必要的工具或原语。
  2. 粒度（Granularity）：优先使用原子原语。工具是基础能力（读文件、写文件、运行 bash、存储记录、发送通知）；功能不是写死的函数，而是提示词中描述的结果，由智能体在循环中达成。工具越原子，智能体使用越灵活；若把决策逻辑打包进工具，判断权就回到了代码里。
  3. 可组合性（Composability）：在原子工具与对等性的基础上，新功能只需编写新提示词即可实现。开发者可通过添加提示词发布新功能，用户也可通过修改或自建提示词定制行为。
  4. 涌现能力（Emergent Capability）：智能体可以完成你未曾明确设计的事情。当工具原子化、对等性保持、提示词可组合时，用户会提出意料之外的请求，而智能体往往能自行找到办法。资料将其描述为一个飞轮：用原子工具与对等性构建 → 用户提出未预料的需求 → 智能体组合工具完成（或失败暴露缺口）→ 观察请求模式 → 添加领域工具或提示词提升常见模式效率 → 重复。
  5. 随时间改进（Improvement Over Time）：智能体原生应用可通过累积上下文与提示词精炼而无需发布代码即可变好。包括累积上下文（如 context.md 文件）、多层级提示词精炼（开发者层、用户层、智能体层），以及高级的自我修改（智能体编辑自身提示词甚至代码，生产环境需考虑审批门、自动检查点回滚、健康检查等安全护栏）。

主要能力与主题

技能覆盖的主题包括：设计架构（从零规划智能体原生系统）、文件与工作区（以文件作为通用接口、共享工作区模式）、工具设计（构建原语工具、动态能力发现、CRUD 完整性）、领域工具（何时添加领域工具而非停留在原语）、执行模式（完成信号、部分完成、上下文限制）、系统提示词（在提示词中定义智能体行为与判断标准）、上下文注入（把运行时应用状态注入智能体提示词）、动作对等、自我修改、产品设计（渐进式披露、潜在需求、审批模式）、移动端模式（iOS 存储、后台执行、检查点/恢复）、测试（测试能力与对等性）、重构（让现有代码更智能体原生）。

使用方式

资料提供了一份「架构评审清单」，在设计智能体原生系统时，应在实现前逐项核对：

  • 核心原则：对等性、粒度、可组合性、涌现能力。
  • 工具设计：外部 API 且智能体应拥有完整访问时使用动态能力发现；每个实体具备创建、读取、更新、删除；工具是原语而非工作流；当 API 负责校验时使用 z.string() 输入而非 z.enum()。
  • 文件与工作区：共享工作区；context.md 模式；按实体划分目录并保持命名一致。
  • 智能体执行：显式 complete_task 工具作为完成信号（而非启发式检测）；多步任务跟踪进度以便恢复；从一开始就为有界上下文设计。
  • 上下文注入：系统提示词包含现有资源（文件、数据、类型）；用用户词汇记录工具能力；长会话刷新上下文或提供 refresh_context 工具。
  • UI 集成：智能体的改动反映到 UI（共享服务、文件监听或事件总线）；智能体写入立即触发 UI 更新；用户可了解智能体能做什么。
  • 移动端（如适用）：检查点/恢复以应对 iOS 应用挂起；iCloud 优先、本地回退以支持多设备同步；成本意识（Haiku/Sonnet/Opus 模型层级选择）。

资料还给出「快速上手」三步示例：

第一步，定义原子工具：

const tools = [
  tool("read_file", "Read any file", { path: z.string() }, ...),
  tool("write_file", "Write any file", { path: z.string(), content: z.string() }, ...),
  tool("list_files", "List directory", { path: z.string() }, ...),
  tool("complete_task", "Signal task completion", { summary: z.string() }, ...),
];

第二步，在系统提示词中写行为：

## Your Responsibilities
When asked to organize content, you should:
1. Read existing files to understand the structure
2. Analyze what organization makes sense
3. Create/move files using your tools
4. Use your judgment about layout and formatting
5. Call complete_task when you're done

You decide the structure. Make it good.

第三步，让智能体在循环中工作：

const result = await agent.run({
  prompt: userMessage,
  tools: tools,
  systemPrompt: systemPrompt,
  // Agent loops until it calls complete_task
});

参考文件

资料列出 references/ 下的参考文件，分为几类：

核心模式：architecture-patterns.md（事件驱动、统一编排器、智能体到 UI）、files-universal-interface.md（为何用文件、组织模式、context.md）、mcp-tool-design.md（工具设计、动态能力发现、CRUD）、from-primitives-to-domain-tools.md（何时添加领域工具、升级为代码）、agent-execution-patterns.md（完成信号、部分完成、上下文限制）、system-prompt-design.md（功能即提示词、判断标准）。

智能体原生纪律：dynamic-context-injection.md（运行时上下文、注入什么）、action-parity-discipline.md（能力映射、对等性工作流）、shared-workspace-architecture.md（共享数据空间、UI 集成）、product-implications.md（渐进式披露、潜在需求、审批）、agent-native-testing.md（测试结果、对等性测试）。

平台特定：mobile-patterns.md（iOS 存储、检查点/恢复、成本意识）、self-modification.md（基于 Git 的演进、护栏）、refactoring-to-prompt-native.md（迁移现有代码）。

适用场景

适合希望构建智能体原生应用的开发者与产品设计者，尤其是需要设计自主智能体、创建 MCP 工具、实现自我修改、把现有应用重构为提示词原生架构，或为智能体原生应用设计测试与对等性验证的场景。

限制与反模式

资料明确指出若干「并非完全智能体原生」的常见做法（不一定错误，但值得识别）：智能体仅作路由器；先按传统方式构建应用再接入智能体；请求/响应式思维（忽略循环）；防御式工具设计（过度约束输入）；在代码中处理快乐路径、智能体只负责执行。

资料特别强调「最大禁忌」：智能体执行你写的代码，而不是自己去想办法。例如把分类、优先级计算、存储、通知全部写进一个 process_feedback 工具，就是让代码做决策；正确做法是提供 store_item、send_message 等原语，并在提示词中描述「按可执行性给重要性打 1-5 分，存储反馈，若 >= 4 则通知」。

其他具体反模式包括：工作流形状的工具（把判断打包进工具）、上下文饥饿（智能体不知道应用里有什么资源）、孤立的 UI 操作（用户能通过 UI 做但智能体做不到）。

关于收费、价格、平台支持范围等具体信息，资料中暂未提供。