eve-agentic-app-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Agentic App Design on Eve Horizon

Eve Horizon 智能体驱动应用设计

Transform a full-stack app into one where agents are primary actors — reasoning, coordinating, remembering, and communicating alongside humans.

将全栈应用转化为以智能体为核心角色的系统——智能体可与人类协同进行推理、协作、记忆与沟通。

When to Use

适用场景

Load this skill when:

Designing an app where agents are primary users alongside (or instead of) humans
Adding agent capabilities to an existing Eve app
Choosing between human-first and agent-first architecture
Deciding how agents should coordinate, remember, and communicate
Planning multi-model inference strategy

在以下场景加载此技能：

设计以智能体为核心用户（替代或配合人类）的应用
为现有Eve应用添加智能体能力
在人类优先与智能体优先架构之间做选择
确定智能体的协作、记忆与沟通方式
规划多模型推理策略

Prerequisite: Start with the Foundation

前置条件：打好基础

Load
eve-fullstack-app-design
first. The agentic layer builds on a solid PaaS foundation. Without a well-designed manifest, service topology, database, pipeline, and deployment strategy, agentic capabilities collapse into chaos.

The progression:

eve-agent-native-design
— Principles (parity, granularity, composability, emergent capability)
eve-fullstack-app-design
— PaaS foundation (manifest, services, DB, pipelines, deploys)
This skill — Agentic layer (agents, teams, inference, memory, events, chat, coordination)

Each layer assumes the previous. Skip none.

请先加载
eve-fullstack-app-design
技能。智能体层构建在稳固的PaaS基础之上。如果没有设计完善的清单（manifest）、服务拓扑、数据库、流水线与部署策略，智能体能力会陷入混乱。

步骤顺序：

eve-agent-native-design
— 设计原则（对等性、粒度、可组合性、涌现能力）
eve-fullstack-app-design
— PaaS基础（清单、服务、数据库、流水线、部署）
本技能 — 智能体层（智能体、团队、推理、记忆、事件、聊天、协作）

每一层都依赖前一层，请勿跳过任何步骤。

Agent Architecture

智能体架构

Defining Agents

定义智能体

Agents are defined in

agents.yaml

(path set via

x-eve.agents.config_path

in the manifest). Each agent is a persona with a skill, access scope, and policies.

yaml

version: 1
agents:
  coder:
    slug: coder
    description: "Implements features and fixes bugs"
    skill: eve-orchestration
    harness_profile: primary-coder
    access:
      envs: [staging]
      services: [api, worker]
    policies:
      permission_policy: auto_edit
      git:
        commit: auto
        push: on_success
    gateway:
      policy: routable

Design decisions for each agent:

Decision	Options	Guidance
Slug	Lowercase, alphanumeric + dashes	Org-unique. Used for chat routing: `@eve coder fix the login bug`
Skill	Any installed skill name	The agent's core competency. One skill per agent.
Harness profile	Named profile from manifest	Decouples agent from specific models. Use profiles, never hardcode harnesses.
Gateway policy	`none` , `discoverable` , `routable`	Default to `none` . Make `routable` only for agents that should receive direct chat.
Permission policy	`default` , `auto_edit` , `never` , `yolo`	Start with `auto_edit` for worker agents. Use `default` for agents that need human approval.
Git policies	`commit` , `push`	`auto` commit + `on_success` push for coding agents. `never` for read-only agents.

智能体在

agents.yaml

中定义（路径通过清单中的

x-eve.agents.config_path

设置）。每个智能体都是具备技能、访问范围与策略的角色。

yaml

version: 1
agents:
  coder:
    slug: coder
    description: "Implements features and fixes bugs"
    skill: eve-orchestration
    harness_profile: primary-coder
    access:
      envs: [staging]
      services: [api, worker]
    policies:
      permission_policy: auto_edit
      git:
        commit: auto
        push: on_success
    gateway:
      policy: routable

每个智能体的设计决策：

决策项	可选选项	指导建议
Slug	小写字母、数字与连字符	在组织内唯一。用于聊天路由： `@eve coder fix the login bug`
Skill	任何已安装的技能名称	智能体的核心能力。每个智能体对应一个技能。
Harness profile	清单中定义的命名配置文件	将智能体与特定模型解耦。使用配置文件，切勿硬编码harness。
Gateway policy	`none` , `discoverable` , `routable`	默认设为 `none` 。仅对需要接收直接聊天的智能体设置为 `routable` 。
Permission policy	`default` , `auto_edit` , `never` , `yolo`	工作类智能体初始设为 `auto_edit` 。对于需要人工审批的智能体使用 `default` 。
Git policies	`commit` , `push`	编码类智能体设为 `auto` 提交 + `on_success` 推送。只读智能体设为 `never` 。

Designing Teams

设计智能体团队

Teams are defined in

teams.yaml

. A team groups agents under a lead with a dispatch strategy.

yaml

version: 1
teams:
  review-council:
    lead: mission-control
    members: [code-reviewer, security-auditor]
    dispatch:
      mode: council
      merge_strategy: majority
  deploy-ops:
    lead: ops-lead
    members: [deploy-agent, monitor-agent]
    dispatch:
      mode: relay

Choose the right dispatch mode:

Mode	When to Use	How It Works
`fanout`	Independent parallel work	Root job + parallel child per member. Best for decomposable tasks.
`council`	Collective judgment	All agents respond, results merged by strategy (majority, unanimous, lead-decides). Best for reviews, audits.
`relay`	Sequential handoff	Lead delegates to first member, output passes to next. Best for staged workflows.

Design principle: Most work is

fanout

. Use

council

only when multiple perspectives genuinely improve the outcome. Use

relay

only when each stage's output is the next stage's input.

智能体团队在

teams.yaml

中定义。团队将多个智能体归到一个负责人下，并指定调度策略。

yaml

version: 1
teams:
  review-council:
    lead: mission-control
    members: [code-reviewer, security-auditor]
    dispatch:
      mode: council
      merge_strategy: majority
  deploy-ops:
    lead: ops-lead
    members: [deploy-agent, monitor-agent]
    dispatch:
      mode: relay

选择合适的调度模式：

模式	适用场景	工作机制
`fanout`	独立并行任务	根任务 + 为每个成员创建并行子任务。最适合可分解的任务。
`council`	集体决策场景	所有智能体响应，结果按策略合并（多数同意、全票通过、负责人决定）。最适合评审、审计场景。
`relay`	顺序交接任务	负责人将任务交给第一个成员，输出传递给下一个成员。最适合分阶段工作流。

设计原则：大多数任务使用

fanout

。仅当多视角能真正提升结果时使用

council

。仅当前一阶段的输出是下一阶段的输入时使用

relay

。

Multi-Model Inference

多模型推理

Harness Profiles

Harness配置文件

Define named profiles in the manifest. Agents reference profiles, never specific harnesses.

yaml

x-eve:
  agents:
    profiles:
      primary-coder:
        - harness: claude
          model: opus-4.5
          reasoning_effort: high
        - harness: codex
          model: gpt-5.2-codex
          reasoning_effort: high
      fast-reviewer:
        - harness: mclaude
          model: sonnet-4.5
          reasoning_effort: medium

Profile entries are a fallback chain: if the first harness is unavailable, the next is tried. Design profiles around capability needs, not provider loyalty.

在清单中定义命名配置文件。智能体引用配置文件，而非特定的harness。

yaml

x-eve:
  agents:
    profiles:
      primary-coder:
        - harness: claude
          model: opus-4.5
          reasoning_effort: high
        - harness: codex
          model: gpt-5.2-codex
          reasoning_effort: high
      fast-reviewer:
        - harness: mclaude
          model: sonnet-4.5
          reasoning_effort: medium

配置文件条目是一个 fallback 链：如果第一个harness不可用，则尝试下一个。围绕能力需求设计配置文件，而非绑定特定供应商。

Model Selection Guidance

模型选择指导

Task Type	Profile Strategy
Complex coding, architecture	High-reasoning model (opus, gpt-5.2-codex)
Code review, documentation	Medium-reasoning model (sonnet, gemini)
Triage, routing, classification	Fast model (haiku-equivalent, low reasoning)
Specialized domains	Choose the model with strongest domain performance

任务类型	配置文件策略
复杂编码、架构设计	高推理能力模型（opus、gpt-5.2-codex）
代码评审、文档编写	中等推理能力模型（sonnet、gemini）
分类、路由、分诊	轻量快速模型（haiku等价模型、低推理消耗）
专业领域任务	选择在该领域表现最优的模型

Managed Models

托管模型

Use managed models (

managed/<name>

) for org-wide or project-wide model policies. The registry merges across scopes: platform <- org <- project.

使用托管模型（

managed/<name>

）实现组织或项目级的模型策略。注册表会跨范围合并配置：平台 <- 组织 <- 项目。

Local Inference

本地推理

For development and cost-sensitive tasks, configure local inference via Ollama targets. Use route policies to direct specific agent types to local models.

对于开发和成本敏感型任务，通过Ollama目标配置本地推理。使用路由策略将特定类型的智能体导向本地模型。

Memory Design

记忆设计

Load

eve-agent-memory

for the full storage primitive catalog. This section focuses on architectural decisions.

加载

eve-agent-memory

技能以获取完整的存储原语目录。本节聚焦于架构决策。

What Goes Where

存储方案选择

Information Type	Storage Primitive	Why
Scratch notes during a job	Workspace files ( `.eve/` )	Ephemeral, dies with the job
Job outputs passed to parent	Job attachments	Survives job completion, addressable by job ID
Rolling conversation context	Threads	Continuity across sessions, summarizable
Curated knowledge	Org Document Store	Versioned, searchable, shared across projects
File trees and assets	Org Filesystem (sync)	Bidirectional sync, local editing
Structured queries	Managed database	SQL, relationships, RLS
Reusable workflows	Skills	Highest-fidelity long-term memory

信息类型	存储原语	原因
任务执行中的临时笔记	工作区文件（ `.eve/` ）	临时存储，随任务结束而销毁
传递给父任务的输出	任务附件	任务完成后保留，可通过任务ID访问
滚动对话上下文	线程（Threads）	跨会话保持连续性，支持摘要
整理后的知识库	组织文档库	版本化、可搜索，跨项目共享
文件树与资产	组织文件系统（同步）	双向同步，支持本地编辑
结构化查询	托管数据库	支持SQL、关系、行级安全（RLS）
可复用工作流	技能（Skills）	最高保真度的长期记忆

Namespace Conventions

命名空间规范

Organize org docs by agent and purpose:

/agents/{agent-slug}/learnings/      — discoveries and patterns
/agents/{agent-slug}/decisions/      — decision records
/agents/{agent-slug}/runbooks/       — operational procedures
/agents/shared/                      — cross-agent shared knowledge
/projects/{project-slug}/            — project-scoped knowledge

按智能体和用途组织组织文档：

/agents/{agent-slug}/learnings/      — 发现与模式总结
/agents/{agent-slug}/decisions/      — 决策记录
/agents/{agent-slug}/runbooks/       — 操作流程
/agents/shared/                      — 跨智能体共享知识
/projects/{project-slug}/            — 项目级知识

Lifecycle Strategy

生命周期策略

Memory without expiry becomes noise. For every storage location, decide:

Who writes? Which agents create and update this knowledge.
Who reads? Which agents query it and when (job start? on demand?).
When does it expire? Tag with creation dates. Build periodic cleanup jobs.
How does it stay current? Search before writing. Update beats create.

无过期机制的记忆会变成噪音。对于每个存储位置，需确定：

谁可以写入？ 哪些智能体可以创建和更新这些知识。
谁可以读取？ 哪些智能体可以查询，以及查询时机（任务启动时？按需查询？）。
何时过期？ 标记创建日期，定期执行清理任务。
如何保持更新？ 写入前先搜索，优先更新而非创建。

Event-Driven Coordination

事件驱动协作

The Event Spine

事件中枢

Events are the nervous system of an agentic app. Use them for reactive automation — things that should happen in response to other things.

事件是智能体应用的神经系统。用于响应式自动化——即某些操作需要响应其他操作而触发。

Trigger Patterns

触发模式

Trigger	Event	Response
Code pushed to main	`github.push`	Run CI pipeline
PR opened	`github.pull_request`	Run review council
Deploy pipeline failed	`system.pipeline.failed`	Run self-healing workflow
Job failed	`system.job.failed`	Run diagnostic agent
Org doc created	`system.doc.created`	Notify subscribers, update indexes
Scheduled maintenance	`cron.tick`	Run audit, cleanup, reporting
Custom app event	`app.*`	Application-specific automation

触发器	事件	响应动作
代码推送到main分支	`github.push`	运行CI流水线
PR创建	`github.pull_request`	启动评审团队工作
部署流水线失败	`system.pipeline.failed`	运行自修复工作流
任务失败	`system.job.failed`	启动诊断智能体
组织文档创建	`system.doc.created`	通知订阅者，更新索引
定期维护	`cron.tick`	运行审计、清理、报告任务
自定义应用事件	`app.*`	应用特定的自动化逻辑

Self-Healing Pattern

自修复模式

Wire system failure events to recovery pipelines:

yaml

pipelines:
  self-heal:
    trigger:
      system:
        event: job.failed
        pipeline: deploy
    steps:
      - name: diagnose
        agent:
          prompt: "Diagnose the failed deploy and suggest a fix"

将系统失败事件连接到恢复流水线：

yaml

pipelines:
  self-heal:
    trigger:
      system:
        event: job.failed
        pipeline: deploy
    steps:
      - name: diagnose
        agent:
          prompt: "Diagnose the failed deploy and suggest a fix"

Custom App Events

自定义应用事件

Emit application-specific events from your services:

bash

eve event emit --type app.invoice.created --source app --payload '{"invoice_id":"inv_123"}'

Wire these to workflows or pipelines in the manifest. Design your app's event vocabulary intentionally — events are the API between your app logic and your agent automation.

从服务中触发应用特定事件：

bash

eve event emit --type app.invoice.created --source app --payload '{"invoice_id":"inv_123"}'

在清单中将这些事件与工作流或流水线关联。需谨慎设计应用的事件词汇——事件是应用逻辑与智能体自动化之间的API。

Chat and Human-Agent Interface

聊天与人机交互

Gateway Architecture

网关架构

Eve supports multiple chat providers through a unified gateway:

Provider	Transport	Best For
Slack	Webhook	Team collaboration, existing Slack workspaces
Nostr	Subscription	Decentralized, privacy-focused, censorship-resistant
WebChat	WebSocket	Browser-native, embedded in your app

Eve通过统一网关支持多种聊天提供商：

提供商	传输方式	最佳场景
Slack	Webhook	团队协作、已有Slack工作区
Nostr	订阅	去中心化、隐私优先、抗审查
WebChat	WebSocket	浏览器原生、嵌入应用

Routing Design

路由设计

Define routes in

chat.yaml

to map inbound messages to agents or teams:

yaml

version: 1
default_route: route_default
routes:
  - id: deploy-route
    match: "deploy|release|ship"
    target: agent:deploy-agent
  - id: review-route
    match: "review|PR|pull request"
    target: team:review-council
  - id: route_default
    match: ".*"
    target: agent:mission-control

Route targets can be

agent:<key>

team:<key>

workflow:<name>

, or

pipeline:<name>

在

chat.yaml

中定义路由，将入站消息映射到智能体或团队：

yaml

version: 1
default_route: route_default
routes:
  - id: deploy-route
    match: "deploy|release|ship"
    target: agent:deploy-agent
  - id: review-route
    match: "review|PR|pull request"
    target: team:review-council
  - id: route_default
    match: ".*"
    target: agent:mission-control

路由目标可以是

agent:<key>

、

team:<key>

、

workflow:<name>

或

pipeline:<name>

。

Gateway vs Backend-Proxied Chat

网关模式 vs 后端代理模式

Approach	When to Use
Gateway provider (WebSocket to Eve)	Simple chat widgets, admin consoles, no backend needed
Backend-proxied ( `POST /internal/orgs/:id/chat/route` )	Production SaaS, when you need to intercept, enrich, or store conversations

If your app needs to add context, filter messages, or maintain its own chat history — proxy through your backend.

方案	适用场景
网关提供商（WebSocket连接Eve）	简单聊天组件、管理控制台，无需后端
后端代理（ `POST /internal/orgs/:id/chat/route` ）	生产级SaaS，需要拦截、丰富或存储对话

如果应用需要添加上下文、过滤消息或维护自己的聊天历史——请通过后端代理。

Thread Continuity

线程连续性

Chat threads maintain context across messages. Thread keys are scoped to the integration account. Design your chat UX to preserve thread context — agents are dramatically more effective when they can reference conversation history.

聊天线程在多条消息间保持上下文。线程键与集成账户绑定。设计聊天UX时需保留线程上下文——智能体能够参考对话历史时，工作效率会大幅提升。

Jobs as Coordination Primitive

任务作为协作原语

Parent-Child Orchestration

父子任务编排

Jobs are the fundamental unit of agent work. Design complex workflows as job trees:

Parent (orchestrator)
├── Child A (research)
├── Child B (implementation)
└── Child C (testing)

The parent dispatches, waits, resumes, synthesizes. Children execute independently. Use

waits_for

relations to express dependencies. See

eve-orchestration

for full patterns.

任务是智能体工作的基本单元。将复杂工作流设计为任务树：

Parent (orchestrator)
├── Child A (research)
├── Child B (implementation)
└── Child C (testing)

父任务负责调度、等待、恢复、合成结果。子任务独立执行。使用

waits_for

关系表达依赖。详见

eve-orchestration

技能中的完整模式。

Structured Context via Attachments

通过附件传递结构化上下文

Pass structured data between agents using job attachments, not giant description strings:

bash

undefined

使用任务附件在智能体间传递结构化数据，而非冗长的描述字符串：

bash

undefined

Child stores findings

子任务存储结果

eve job attach $EVE_JOB_ID --name findings.json --content '{"patterns": [...]}'

Parent reads on resume

父任务恢复时读取

eve job attachment $CHILD_JOB_ID findings.json --out ./child-findings.json

undefined

eve job attachment $CHILD_JOB_ID findings.json --out ./child-findings.json

undefined

Resource Refs for Document Mounting

资源引用用于文档挂载

Pin specific org document versions as job inputs:

bash

eve job create \
  --description "Review the approved plan" \
  --resource-refs='[{"uri":"org_docs:/pm/features/FEAT-123.md@v3","label":"Plan","mount_path":"pm/plan.md"}]'

The document is hydrated into the workspace at the mount path. Events track hydration success or failure.

将特定版本的组织文档作为任务输入：

bash

eve job create \
  --description "Review the approved plan" \
  --resource-refs='[{"uri":"org_docs:/pm/features/FEAT-123.md@v3","label":"Plan","mount_path":"pm/plan.md"}]'

文档会被加载到工作区的指定挂载路径。事件会跟踪加载成功或失败。

Coordination Threads

协作线程

When teams dispatch work, a coordination thread (

coord:job:{parent_job_id}

) links parent and children. Children read

.eve/coordination-inbox.md

for sibling context. Post updates via

eve thread post

. The lead agent can

eve supervise

to monitor the job tree.

当团队调度任务时，协作线程（

coord:job:{parent_job_id}

）会关联父任务与子任务。子任务可读取

.eve/coordination-inbox.md

获取兄弟任务的上下文。通过

eve thread post

发布更新。负责人智能体可使用

eve supervise

监控任务树。

Access and Security

访问与安全

Service Accounts

服务账户

Backend services need non-user tokens for API calls. Use

eve auth mint

to create scoped tokens:

bash

eve auth mint --email app-bot@example.com --project proj_xxx --role admin

Design each service account with minimal necessary scope.

后端服务需要非用户令牌进行API调用。使用

eve auth mint

创建范围受限的令牌：

bash

eve auth mint --email app-bot@example.com --project proj_xxx --role admin

为每个服务账户设计最小必要权限范围。

Access Groups

访问组

Segment data-plane access using groups. Groups control who can read/write org docs, org filesystem paths, and database schemas:

yaml

undefined

使用访问组分隔数据平面访问权限。访问组控制谁可以读写组织文档、组织文件系统路径和数据库 schema：

yaml

undefined

.eve/access.yaml

version: 2 access: groups: eng-team: name: Engineering members: - type: user id: user_abc bindings: - subject: { type: group, id: eng-team } roles: [data-reader] scope: orgdocs: { allow_prefixes: ["/agents/shared/"] } envdb: { schemas: ["public"] }


Sync with `eve access sync --file .eve/access.yaml --org org_xxx`.


使用`eve access sync --file .eve/access.yaml --org org_xxx`同步配置。

Agent Permission Policies

智能体权限策略

Policy	Use Case
`default`	Interactive agents that need human approval for risky actions
`auto_edit`	Worker agents that edit code and files autonomously
`never`	Read-only agents (auditors, reviewers)
`yolo`	Fully autonomous agents in controlled environments (use carefully)

策略	适用场景
`default`	需要人类审批风险操作的交互式智能体
`auto_edit`	可自主编辑代码和文件的工作类智能体
`never`	只读智能体（审计员、评审员）
`yolo`	受控环境下的完全自主智能体（谨慎使用）

Policy-as-Code

策略即代码

Declare all access in

.eve/access.yaml

and sync declaratively. This ensures access is version-controlled, reviewable, and reproducible. See

eve-auth-and-secrets

for the full v2 policy schema.

在

.eve/access.yaml

中声明所有访问权限，并以声明式方式同步。确保访问权限受版本控制、可评审、可复现。详见

eve-auth-and-secrets

技能中的完整v2策略 schema。

The Agentic Checklist

智能体应用检查清单

Agent Architecture:

Agents defined in
```
agents.yaml
```
with clear slug, skill, and profile
Teams defined in
```
teams.yaml
```
with appropriate dispatch modes
Gateway policies set intentionally (not everything routable)
Chat routes defined for inbound message handling

Inference:

Harness profiles defined in manifest (agents reference profiles, not harnesses)
Fallback chains in profiles for resilience
Model choice matches task complexity

Memory:

Storage primitive chosen for each information type (see table above)
Namespace conventions established for org docs
Lifecycle and expiry strategy defined
Agents search before writing (update beats create)

Events:

Trigger patterns wired for key events (push, PR, failures)
Self-healing pipeline exists for deploy and job failures
Custom app events defined for domain-specific automation

Chat:

Gateway provider chosen (Slack, Nostr, WebChat, or multiple)
Chat routing configured (
```
chat.yaml
```
)
Gateway vs backend-proxied decision made
Thread continuity preserved in UX

Coordination:

Complex work decomposed as job trees (parent-child)
Attachments used for structured context passing
Coordination threads used for team communication
Resource refs used for document mounting

Security:

Service accounts created for backend services
Access groups defined for data-plane segmentation
Agent permission policies appropriate to each agent's role
Access policy declared as code (
```
.eve/access.yaml
```
)

The Real Test — Is This App Truly Agent-Native?

Agents can do everything users can (parity)
Adding capability means writing prompts, not code (composability)
Agents coordinate through platform primitives, not custom glue (granularity)
Agents have surprised you with unexpected solutions (emergent capability)

智能体架构：

智能体在
```
agents.yaml
```
中定义，包含清晰的slug、技能和配置文件
智能体团队在
```
teams.yaml
```
中定义，使用合适的调度模式
网关策略经过合理设置（并非所有智能体都设为可路由）
为入站消息处理配置了聊天路由

推理能力：

在清单中定义了Harness配置文件（智能体引用配置文件而非直接引用harness）
配置文件中包含fallback链以提升韧性
模型选择与任务复杂度匹配

记忆设计：

为每种信息类型选择了合适的存储原语（见上表）
建立了组织文档的命名空间规范
定义了生命周期与过期策略
智能体写入前先搜索（优先更新而非创建）

事件系统：

为关键事件（推送、PR、失败）配置了触发模式
为部署和任务失败配置了自修复流水线
为领域特定自动化定义了自定义应用事件

聊天功能：

选择了合适的网关提供商（Slack、Nostr、WebChat或多种组合）
配置了聊天路由（
```
chat.yaml
```
）
确定了使用网关模式还是后端代理模式
在UX中保留了线程连续性

协作能力：

将复杂工作分解为任务树（父子结构）
使用附件传递结构化上下文
使用协作线程实现团队沟通
使用资源引用挂载文档

安全配置：

为后端服务创建了服务账户
为数据平面对齐定义了访问组
为每个智能体配置了与其角色匹配的权限策略
以代码形式声明了访问策略（
```
.eve/access.yaml
```
）

真正的测试——这是真正的智能体原生应用吗？

智能体可以完成所有用户能完成的操作（对等性）
添加能力只需编写提示词，无需编写代码（可组合性）
智能体通过平台原语协作，而非自定义胶水代码（粒度）
智能体曾为你带来意外的解决方案（涌现能力）

Cross-References

交叉引用

Principles:
```
eve-agent-native-design
```
— parity, granularity, composability, emergent capability
PaaS foundation:
```
eve-fullstack-app-design
```
— manifest, services, DB, pipelines, deploys
Storage primitives:
```
eve-agent-memory
```
— detailed guidance on each memory primitive
Job orchestration:
```
eve-orchestration
```
— depth propagation, parallel decomposition, control signals

Agents and teams reference:

eve-read-eve-docs

→

references/agents-teams.md

Harness execution:

eve-read-eve-docs

→

references/harnesses.md

Chat gateway:
```
eve-read-eve-docs
```
→
```
references/gateways.md
```
Events and triggers:
```
eve-read-eve-docs
```
→
```
references/events.md
```

设计原则：
```
eve-agent-native-design
```
— 对等性、粒度、可组合性、涌现能力
PaaS基础：
```
eve-fullstack-app-design
```
— 清单、服务、数据库、流水线、部署
存储原语：
```
eve-agent-memory
```
— 各存储原语的详细指导
任务编排：
```
eve-orchestration
```
— 深度传播、并行分解、控制信号

智能体与团队参考：

eve-read-eve-docs

→

references/agents-teams.md

Harness执行：

eve-read-eve-docs

→

references/harnesses.md

聊天网关：
```
eve-read-eve-docs
```
→
```
references/gateways.md
```
事件与触发器：
```
eve-read-eve-docs
```
→
```
references/events.md
```