尧图网页设计 
Electric Agents 单智能体模式Single-Agent Pattern如何设计一个无编排的独立 LLM 实体【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric导读single-agent 是 Electric Agentselectric-ax/agents-runtime实体设计体系中最基础、也是默认的实体形态一个由 LLM 驱动、不做任何实体间协调不 spawn、不 observe、不 send的独立实体。本文以 designing-entities skill 的 single-agent 模式参考文档 为骨架完整讲解该模式的定义、适用条件、Handler 骨架、状态设计、审查清单与反模式并借助仓库内 Horton 内建助手与 playground 示例进行源码级佐证。读完本文你将掌握如何用registry.define(...)写出一个生产可用的单智能体实体并能正确判断什么时候该停留在单智能体、什么时候该切换到协调型模式。single-agent 模式是什么模式参考文档对 single-agent 给出了精确定义一个无协调的、由 LLM 驱动的实体a single LLM-driven entity with no coordination。Handler 主体本质上就是useAgent agent.run。可选的自定义工具自定义、有状态或ctx.electricTools辅助工具用于扩展其能力边界。用一句话概括一个实体、一个 LLM 循环、零协调调用。整个 handler 的工作量收敛为配置 Agent → 运行 Agent所有业务能力通过工具tool注入而不是通过派生其他实体来实现。在 designing-entities skill 的七种协调模式single-agent、manager-worker、pipeline、map-reduce、dispatcher、blackboard、reactive-observers中single-agent 被明确定位为基准实体形态baseline entity shape——它没有专门的独立模式文档是其他一切协调模式的起点。其余六种模式本质都是在一个 LLM 循环之上叠加实体间协调能力。官方示范模式参考文档指出Electric Agents 内置助手Horton就是 single-agent 形态的典型范例the built-in assistant, an exemplar of the single-agent shape。Horton 的完整实现位于 packages/agents/src/agents/horton.ts官方文档见 website/docs/agents/entities/agents/horton.md。此外模式文档与 SKILL.md 将examples/durable-agents-playground/src/standalone/assistant.ts列为 canonical 示例在当前仓库快照中该目录并未包含playground 以独立示例仓库形式维护与单智能体形态最接近的可运行参考是 examples/agents-playground 中的实体文件与 server.ts。何时适用适用条件判定模式文档给出了四条判定标准满足其一即可考虑 single-agent条件说明一个实体完成全部工作任务不需要拆分成多个角色的协作不存在ctx.spawn/ctx.observe/ctx.send调用不派生子实体、不观察其他实体、不向其他实体发消息不存在跨实体的共享状态没有多个实体读写同一份数据可以带与外部世界交互的自定义工具HTTP、文件系统、MCP 服务器等均可可以带持久化自定义状态例如对话记忆、缓存结果、用户偏好从 skill 的 pattern-triggers.md 触发词表可以反推判定逻辑当开发者的描述中不命中任何协调触发词multiple perspectivessequential stagesparallelclassify and routeshared knowledge basemonitor等且没有其他实体参与、只有一个 LLM 循环时直接推断为single-agent。该文档还给出一个典型的工作示例一个用网络搜索来回答问题的 Agent。未命中任何协调触发词 → 无协调信号确认问题这个实体是否会 spawn/observe 其他实体还是只是一个 LLM 循环若只是带工具的循环 → 判定为 single-agent。必需状态默认无状态按需加持久化模式文档明确single-agent 通常不需要任何自定义状态Often none。只有当 Agent 需要在多次 wake 之间持久化某些内容时才添加自定义状态典型场景包括对话记忆conversation memory缓存结果cached results用户偏好user preferences这与运行时持久状态必须放在ctx.db的约定一致通用审查清单review-checklist.md中的 H3 规则强调跨 wake 的状态绝不能放在模块级闭包里进程重启会清空闭包必须写入由持久化流durable stream支撑的ctx.db。Handler 骨架useAgent agent.run模式文档给出的最小骨架如下async handler(ctx) { ctx.useAgent({ systemPrompt: ..., model: claude-sonnet-4-5-20250929, tools: [...ctx.electricTools, ...customTools], }) await ctx.agent.run() }骨架背后的运行时契约对照运行时实现这个骨架的每一行都有对应的强制约束ctx.useAgent(...)必须在ctx.agent.run()之前调用。在 context-factory.ts 中agent.run()执行时会先检查agentConfig是否已设置async run(input?, abortSignal?) { if (!agentConfig) { throw new Error([agent-runtime] agent.run() called without useAgent().) } ... }useAgent的实现context-factory.ts本质是把传入的AgentConfig存起来并返回AgentHandleuseAgent(cfg) { agentConfig cfg return agent },类型签名定义在 types.tsuseAgent: (config: AgentConfig) AgentHandle。...ctx.electricTools必须展开进tools数组且放在首位通用清单 A1。运行时协调工具spawn、observe、send 等就存放在ctx.electricTools类型见 types.ts注入点见 context-factory.ts。漏掉它会导致所有协调功能静默失效即使 single-agent 本身不调用 spawn/observe保留它也能让 Agent 具备必要的运行时能力如定时调度、发送消息。model必须是真实的 Claude 模型标识符通用清单 A4例如claude-sonnet-4-5-20250929。未知模型 ID 会在调用 provider 时失败。systemPrompt必须是非空字符串通用清单 A5。自定义工具的execute必须返回{ content: [...], details: {...} }通用清单 A3details即使为空对象也必须返回否则 Agent 消费工具结果时会在运行时崩溃。独立应用的特殊注意事项通用清单 AW1 指出独立应用standalone app中ctx.electricTools默认是空数组必须显式传入createElectricTools。参考 examples/agents-playground/lib/electric-tools.ts自定义 electric tools 通过createElectricTools(ctx)工厂返回例如upsert_cron_schedule、delete_schedule工具然后在 server.ts 中传入createRuntimeHandler({ ..., createElectricTools })。Electric Agents dev server 会自动接线独立应用必须手动开启。使用自定义状态firstWake 初始化如果确实需要持久化自定义状态模式文档给出的初始化范式是在firstWake中写入默认行且必须同时用状态查询做幂等保护async handler(ctx) { if (ctx.firstWake !ctx.db.collections.memory?.get(initialized)) { ctx.db.actions.memory_insert({ row: { key: initialized, value: true } }) } // ... useAgent, run ... }关键原因通用清单 H4 与 Gotchas 第 5 条ctx.firstWake只在实体的第一次 wake时为true进程重启后该标志位正确地变为false因此仅靠firstWake保护的初始化逻辑无法在重启后自愈self-heal。安全的幂等初始化必须双重防护ctx.firstWake 读状态判断如上面的?.get(initialized)检查。ctx.db.collections.*提供get/toArray读取ctx.db.actions.*提供insert/update/delete写入详见 SKILL.md 对 state collection proxy 的说明。注意 Gotchas 第 6 条insert/update/delete是 fire-and-forget 的事务式写入如需等待落盘要用tx.isPersisted.promise。不变量Invariants模式文档用三条硬性不变量约束 single-agent handler 的形态审查时逐条核对Handler 主体中不允许出现ctx.spawn、ctx.observe、ctx.send不允许出现mkdb/observe(db(...))共享状态句柄ctx.useAgent与ctx.agent.run()是 handler 的核心——任何超出它的工作都是可疑的复杂度。模式专属审查清单Pattern-specific Review Checklist在 skill 的 phase 4Review阶段除了通用审查清单 review-checklist.md 之外single-agent 模式文档要求额外应用以下四条规则#规则原因SA1handler 中无ctx.spawn、ctx.observe、ctx.send调用若出现则不再是 single-agent应切换到对应的协调模式SA2无ctx.mkdb/ctx.observe(db(...))共享状态是黑板blackboard信号需切换模式SA3Handler 主体收敛为可选的 firstWake 初始化useAgentagent.run()任何额外工作都是代码坏味道single-agent handler 内部的复杂度通常意味着设计应拆分到多个实体SA4仅当ctx.args确实被读取时才声明creationSchema避免声明从未使用的 schemaSA4 与通用清单 S3/S6 联动ctx.args的类型是ReadonlyRecordstring, unknown见 types.ts声明creationSchema后 spawn 时会做校验但 handler 内仍需显式 cast/parse 才能获得类型安全。审查报告输出格式skill 的 phase 4 要求以✓/✗/N/A逐条汇报例如Universal checks: ✓ H1 Handler signature correct ✓ A1 ...ctx.electricTools spread first N/A S3 creationSchema — no spawn args expected Pattern-specific (single-agent): ✓ SA1 No spawn/observe/send in handler ✓ SA3 Handler reduces to firstWake init useAgent agent.run() N/A SA4 creationSchema — ctx.args not read反模式Anti-patterns模式文档列出三条必须警惕的反模式内联编排逻辑Inlining orchestration logicAgent 先做 X然后如果条件 Y 成立就做 Z——如果 Z 是不同类型的工作这就应该是两个实体而不是在 single-agent handler 里硬塞流程控制。应改用pipeline或manager-worker模式。用inboxSchemas做同步请求/响应inbox 是 wake 信号不是阻塞式 RPC。如果 Agent 需要回复循环reply loop应该由 LLM 通过工具调用来驱动而不是靠消息信箱往返。持久化瞬时状态Persisting transient state如果某个数据只在单次 wake 内有意义用局部变量即可不要写入ctx.db。持久化流是有代价的只为跨 wake 的数据付这个代价。实战参照Horton 内建助手的 single-agent 实现Horton 是官方认定的 single-agent 范例其实现packages/agents/src/agents/horton.ts完整呈现了本文介绍的骨架。在 horton.ts 中可以看到模式文档骨架的完整落地ctx.useAgent({ systemPrompt: buildHortonSystemPrompt(sandboxCwd, { ... }), ...modelConfig, tools: tools as AgentTool[], ...(streamFn { streamFn }), ...(onStepEnd { onStepEnd }), }) try { await ctx.agent.run(undefined, budgetAbort.signal) } catch (err) { ... }Horton 的工具集见 website/docs/agents/entities/agents/horton.md 的工具表展示了用工具扩展能力而非用实体扩展的 single-agent 思路bash、read、write、edit、web_search、fetch_url、spawn_worker、fork、observe_pg_sync、send、set_title等全部以工具形式注入Agent 在一个循环内自主决策调用而不是由 handler 代码编排。HORTON_MODEL常量定义于 horton.tsclaude-sonnet-4-6印证了模型 ID 必须是真实标识符的清单规则。Horton 还展示了 single-agent 可以安全叠加的特性标题生成用低成本的辅助模型首次运行结束后通过ctx.setTag(title, title)持久化会话标题——这正是模式文档所说持久化用户偏好/状态的落地样例且失败仅记录日志、不影响实体继续运行。实体注册与接线设计评审通过后skill phase 5single-agent 实体以工厂函数形式导出并注册。SKILL.md 规定的文件形态import type { EntityRegistry } from electric-ax/agents-runtime import { z } from zod/v4 // schemas (creationSchema, inboxSchemas, collection schemas) go here export function registerName(registry: EntityRegistry) { registry.define(type, { description: ..., creationSchema, inboxSchemas, state: { ... }, async handler(ctx, wake) { ... }, }) }接线方式参照 examples/agents-playground/server.ts创建createEntityRegistry()后依次registerPerspectives(registry)/registerResearcher(registry)再传给createRuntimeHandler({ baseUrl, serveEndpoint, registry, createElectricTools })。SKILL.md 明确要求skill 只写这一个实体文件不自动修改应用的 registry 组合文件接线由开发者在entities/registry.ts或server.ts中手动完成。两个启动前提值得注意通用清单 AW2进程环境变量必须包含ANTHROPIC_API_KEY及其他 provider key否则agent.run()在首次 wake 时抛错server.ts 在启动时检查并给出警告。若实体展开...ctx.electricTools并期望使用调度工具独立应用必须传入createElectricTools通用清单 AW1。小结从 single-agent 出发的设计决策路径single-agent 是 Electric Agents 实体设计的默认起点。判定流程可以归纳为一条简洁的决策链描述中是否有实体间协调信号spawn / observe / send / 共享状态 / 观察其他实体没有 →single-agenthandler 可选 firstWake 初始化useAgentagent.run()能力全部通过工具注入。有 → 按 pattern-triggers.md 的触发词表与消歧问题流切换至 manager-worker、pipeline、map-reduce、dispatcher、blackboard 或 reactive-observers。保持 handler 简单是 single-agent 的第一原则SA3一旦单个 handler 内部开始出现编排逻辑就该考虑拆分实体而不是继续堆复杂度。进一步阅读模式判定与消歧流程pattern-triggers.md通用审查清单与 Gotchas 目录review-checklist.md实体设计五阶段工作流SKILL.md其它六种协调模式参考references/patternsmanager-worker、pipeline、map-reduce、dispatcher、blackboard、reactive-observers运行时 ctx API 实现context-factory.ts、types.tssingle-agent 范例实体Hortonpackages/agents/src/agents/horton.ts、horton.md【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Electric Agents 单智能体模式（Single-Agent Pattern）：如何设计一个无编排的独立 LLM 实体
Electric Agents 单智能体模式Single-Agent Pattern如何设计一个无编排的独立 LLM 实体【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric导读single-agent 是 Electric Agentselectric-ax/agents-runtime实体设计体系中最基础、也是默认的实体形态一个由 LLM 驱动、不做任何实体间协调不 spawn、不 observe、不 send的独立实体。本文以 designing-entities skill 的 single-agent 模式参考文档 为骨架完整讲解该模式的定义、适用条件、Handler 骨架、状态设计、审查清单与反模式并借助仓库内 Horton 内建助手与 playground 示例进行源码级佐证。读完本文你将掌握如何用registry.define(...)写出一个生产可用的单智能体实体并能正确判断什么时候该停留在单智能体、什么时候该切换到协调型模式。single-agent 模式是什么模式参考文档对 single-agent 给出了精确定义一个无协调的、由 LLM 驱动的实体a single LLM-driven entity with no coordination。Handler 主体本质上就是useAgent agent.run。可选的自定义工具自定义、有状态或ctx.electricTools辅助工具用于扩展其能力边界。用一句话概括一个实体、一个 LLM 循环、零协调调用。整个 handler 的工作量收敛为配置 Agent → 运行 Agent所有业务能力通过工具tool注入而不是通过派生其他实体来实现。在 designing-entities skill 的七种协调模式single-agent、manager-worker、pipeline、map-reduce、dispatcher、blackboard、reactive-observers中single-agent 被明确定位为基准实体形态baseline entity shape——它没有专门的独立模式文档是其他一切协调模式的起点。其余六种模式本质都是在一个 LLM 循环之上叠加实体间协调能力。官方示范模式参考文档指出Electric Agents 内置助手Horton就是 single-agent 形态的典型范例the built-in assistant, an exemplar of the single-agent shape。Horton 的完整实现位于 packages/agents/src/agents/horton.ts官方文档见 website/docs/agents/entities/agents/horton.md。此外模式文档与 SKILL.md 将examples/durable-agents-playground/src/standalone/assistant.ts列为 canonical 示例在当前仓库快照中该目录并未包含playground 以独立示例仓库形式维护与单智能体形态最接近的可运行参考是 examples/agents-playground 中的实体文件与 server.ts。何时适用适用条件判定模式文档给出了四条判定标准满足其一即可考虑 single-agent条件说明一个实体完成全部工作任务不需要拆分成多个角色的协作不存在ctx.spawn/ctx.observe/ctx.send调用不派生子实体、不观察其他实体、不向其他实体发消息不存在跨实体的共享状态没有多个实体读写同一份数据可以带与外部世界交互的自定义工具HTTP、文件系统、MCP 服务器等均可可以带持久化自定义状态例如对话记忆、缓存结果、用户偏好从 skill 的 pattern-triggers.md 触发词表可以反推判定逻辑当开发者的描述中不命中任何协调触发词multiple perspectivessequential stagesparallelclassify and routeshared knowledge basemonitor等且没有其他实体参与、只有一个 LLM 循环时直接推断为single-agent。该文档还给出一个典型的工作示例一个用网络搜索来回答问题的 Agent。未命中任何协调触发词 → 无协调信号确认问题这个实体是否会 spawn/observe 其他实体还是只是一个 LLM 循环若只是带工具的循环 → 判定为 single-agent。必需状态默认无状态按需加持久化模式文档明确single-agent 通常不需要任何自定义状态Often none。只有当 Agent 需要在多次 wake 之间持久化某些内容时才添加自定义状态典型场景包括对话记忆conversation memory缓存结果cached results用户偏好user preferences这与运行时持久状态必须放在ctx.db的约定一致通用审查清单review-checklist.md中的 H3 规则强调跨 wake 的状态绝不能放在模块级闭包里进程重启会清空闭包必须写入由持久化流durable stream支撑的ctx.db。Handler 骨架useAgent agent.run模式文档给出的最小骨架如下async handler(ctx) { ctx.useAgent({ systemPrompt: ..., model: claude-sonnet-4-5-20250929, tools: [...ctx.electricTools, ...customTools], }) await ctx.agent.run() }骨架背后的运行时契约对照运行时实现这个骨架的每一行都有对应的强制约束ctx.useAgent(...)必须在ctx.agent.run()之前调用。在 context-factory.ts 中agent.run()执行时会先检查agentConfig是否已设置async run(input?, abortSignal?) { if (!agentConfig) { throw new Error([agent-runtime] agent.run() called without useAgent().) } ... }useAgent的实现context-factory.ts本质是把传入的AgentConfig存起来并返回AgentHandleuseAgent(cfg) { agentConfig cfg return agent },类型签名定义在 types.tsuseAgent: (config: AgentConfig) AgentHandle。...ctx.electricTools必须展开进tools数组且放在首位通用清单 A1。运行时协调工具spawn、observe、send 等就存放在ctx.electricTools类型见 types.ts注入点见 context-factory.ts。漏掉它会导致所有协调功能静默失效即使 single-agent 本身不调用 spawn/observe保留它也能让 Agent 具备必要的运行时能力如定时调度、发送消息。model必须是真实的 Claude 模型标识符通用清单 A4例如claude-sonnet-4-5-20250929。未知模型 ID 会在调用 provider 时失败。systemPrompt必须是非空字符串通用清单 A5。自定义工具的execute必须返回{ content: [...], details: {...} }通用清单 A3details即使为空对象也必须返回否则 Agent 消费工具结果时会在运行时崩溃。独立应用的特殊注意事项通用清单 AW1 指出独立应用standalone app中ctx.electricTools默认是空数组必须显式传入createElectricTools。参考 examples/agents-playground/lib/electric-tools.ts自定义 electric tools 通过createElectricTools(ctx)工厂返回例如upsert_cron_schedule、delete_schedule工具然后在 server.ts 中传入createRuntimeHandler({ ..., createElectricTools })。Electric Agents dev server 会自动接线独立应用必须手动开启。使用自定义状态firstWake 初始化如果确实需要持久化自定义状态模式文档给出的初始化范式是在firstWake中写入默认行且必须同时用状态查询做幂等保护async handler(ctx) { if (ctx.firstWake !ctx.db.collections.memory?.get(initialized)) { ctx.db.actions.memory_insert({ row: { key: initialized, value: true } }) } // ... useAgent, run ... }关键原因通用清单 H4 与 Gotchas 第 5 条ctx.firstWake只在实体的第一次 wake时为true进程重启后该标志位正确地变为false因此仅靠firstWake保护的初始化逻辑无法在重启后自愈self-heal。安全的幂等初始化必须双重防护ctx.firstWake 读状态判断如上面的?.get(initialized)检查。ctx.db.collections.*提供get/toArray读取ctx.db.actions.*提供insert/update/delete写入详见 SKILL.md 对 state collection proxy 的说明。注意 Gotchas 第 6 条insert/update/delete是 fire-and-forget 的事务式写入如需等待落盘要用tx.isPersisted.promise。不变量Invariants模式文档用三条硬性不变量约束 single-agent handler 的形态审查时逐条核对Handler 主体中不允许出现ctx.spawn、ctx.observe、ctx.send不允许出现mkdb/observe(db(...))共享状态句柄ctx.useAgent与ctx.agent.run()是 handler 的核心——任何超出它的工作都是可疑的复杂度。模式专属审查清单Pattern-specific Review Checklist在 skill 的 phase 4Review阶段除了通用审查清单 review-checklist.md 之外single-agent 模式文档要求额外应用以下四条规则#规则原因SA1handler 中无ctx.spawn、ctx.observe、ctx.send调用若出现则不再是 single-agent应切换到对应的协调模式SA2无ctx.mkdb/ctx.observe(db(...))共享状态是黑板blackboard信号需切换模式SA3Handler 主体收敛为可选的 firstWake 初始化useAgentagent.run()任何额外工作都是代码坏味道single-agent handler 内部的复杂度通常意味着设计应拆分到多个实体SA4仅当ctx.args确实被读取时才声明creationSchema避免声明从未使用的 schemaSA4 与通用清单 S3/S6 联动ctx.args的类型是ReadonlyRecordstring, unknown见 types.ts声明creationSchema后 spawn 时会做校验但 handler 内仍需显式 cast/parse 才能获得类型安全。审查报告输出格式skill 的 phase 4 要求以✓/✗/N/A逐条汇报例如Universal checks: ✓ H1 Handler signature correct ✓ A1 ...ctx.electricTools spread first N/A S3 creationSchema — no spawn args expected Pattern-specific (single-agent): ✓ SA1 No spawn/observe/send in handler ✓ SA3 Handler reduces to firstWake init useAgent agent.run() N/A SA4 creationSchema — ctx.args not read反模式Anti-patterns模式文档列出三条必须警惕的反模式内联编排逻辑Inlining orchestration logicAgent 先做 X然后如果条件 Y 成立就做 Z——如果 Z 是不同类型的工作这就应该是两个实体而不是在 single-agent handler 里硬塞流程控制。应改用pipeline或manager-worker模式。用inboxSchemas做同步请求/响应inbox 是 wake 信号不是阻塞式 RPC。如果 Agent 需要回复循环reply loop应该由 LLM 通过工具调用来驱动而不是靠消息信箱往返。持久化瞬时状态Persisting transient state如果某个数据只在单次 wake 内有意义用局部变量即可不要写入ctx.db。持久化流是有代价的只为跨 wake 的数据付这个代价。实战参照Horton 内建助手的 single-agent 实现Horton 是官方认定的 single-agent 范例其实现packages/agents/src/agents/horton.ts完整呈现了本文介绍的骨架。在 horton.ts 中可以看到模式文档骨架的完整落地ctx.useAgent({ systemPrompt: buildHortonSystemPrompt(sandboxCwd, { ... }), ...modelConfig, tools: tools as AgentTool[], ...(streamFn { streamFn }), ...(onStepEnd { onStepEnd }), }) try { await ctx.agent.run(undefined, budgetAbort.signal) } catch (err) { ... }Horton 的工具集见 website/docs/agents/entities/agents/horton.md 的工具表展示了用工具扩展能力而非用实体扩展的 single-agent 思路bash、read、write、edit、web_search、fetch_url、spawn_worker、fork、observe_pg_sync、send、set_title等全部以工具形式注入Agent 在一个循环内自主决策调用而不是由 handler 代码编排。HORTON_MODEL常量定义于 horton.tsclaude-sonnet-4-6印证了模型 ID 必须是真实标识符的清单规则。Horton 还展示了 single-agent 可以安全叠加的特性标题生成用低成本的辅助模型首次运行结束后通过ctx.setTag(title, title)持久化会话标题——这正是模式文档所说持久化用户偏好/状态的落地样例且失败仅记录日志、不影响实体继续运行。实体注册与接线设计评审通过后skill phase 5single-agent 实体以工厂函数形式导出并注册。SKILL.md 规定的文件形态import type { EntityRegistry } from electric-ax/agents-runtime import { z } from zod/v4 // schemas (creationSchema, inboxSchemas, collection schemas) go here export function registerName(registry: EntityRegistry) { registry.define(type, { description: ..., creationSchema, inboxSchemas, state: { ... }, async handler(ctx, wake) { ... }, }) }接线方式参照 examples/agents-playground/server.ts创建createEntityRegistry()后依次registerPerspectives(registry)/registerResearcher(registry)再传给createRuntimeHandler({ baseUrl, serveEndpoint, registry, createElectricTools })。SKILL.md 明确要求skill 只写这一个实体文件不自动修改应用的 registry 组合文件接线由开发者在entities/registry.ts或server.ts中手动完成。两个启动前提值得注意通用清单 AW2进程环境变量必须包含ANTHROPIC_API_KEY及其他 provider key否则agent.run()在首次 wake 时抛错server.ts 在启动时检查并给出警告。若实体展开...ctx.electricTools并期望使用调度工具独立应用必须传入createElectricTools通用清单 AW1。小结从 single-agent 出发的设计决策路径single-agent 是 Electric Agents 实体设计的默认起点。判定流程可以归纳为一条简洁的决策链描述中是否有实体间协调信号spawn / observe / send / 共享状态 / 观察其他实体没有 →single-agenthandler 可选 firstWake 初始化useAgentagent.run()能力全部通过工具注入。有 → 按 pattern-triggers.md 的触发词表与消歧问题流切换至 manager-worker、pipeline、map-reduce、dispatcher、blackboard 或 reactive-observers。保持 handler 简单是 single-agent 的第一原则SA3一旦单个 handler 内部开始出现编排逻辑就该考虑拆分实体而不是继续堆复杂度。进一步阅读模式判定与消歧流程pattern-triggers.md通用审查清单与 Gotchas 目录review-checklist.md实体设计五阶段工作流SKILL.md其它六种协调模式参考references/patternsmanager-worker、pipeline、map-reduce、dispatcher、blackboard、reactive-observers运行时 ctx API 实现context-factory.ts、types.tssingle-agent 范例实体Hortonpackages/agents/src/agents/horton.ts、horton.md【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考