自托管 Agent 架构指南 · 更新 2026-07-05

Self-hosted Agent Stack Architecture Guide：Runtime、Memory、Sandboxes、Gateways、Domain Workflows、Secrets 与 Recovery

面向 self-hosted agent runtime、persistent memory、tool execution、communication gateways、domain workflows、scheduling、provider credentials、observability、backup 与 recovery 的实用架构指南。

Self-hosted agent stack 很少是一个产品就能解决的问题。真正可运营的架构需要把 agent runtime 与 persistent memory、privileged tool execution、messaging gateway、domain workflow、scheduled jobs、provider credentials，以及 bad run/compromised integration 后的恢复能力分开设计。

RepoDaily 当前 self-hosted 项目更像不同层，而不是互相替代的同类产品。DeerFlow 是包含 subagents、memory、sandboxes、skills 与 gateway 的广义 long-horizon agent harness；Hermes Agent 强调 always-available personal agent、cross-session learning、reusable skills、channels、cron 与多种 deployment backends；Cognee 是独立 memory control plane；Vibe-Trading 是带 backtests、tools、swarm workflows 与 persistent state 的领域型 research agent；Daily Stock Analysis 则是 scheduled intelligence pipeline + dashboard + notifications。

RepoDaily 判断

先选择 operating model，而不是先选 feature 最多的 repo。当产品需要 multi-step research、code execution、subagents、sandboxes 与 programmable gateway 时，可从 DeerFlow 这类 broad runtime 起步；当 persistent personal context、skill learning、channels、cron 与 flexible deployment 是核心时，可评估 Hermes Agent；当多个 agent 需要 durable、queryable、governed context 时，把 Cognee 这类 memory layer 独立出来；Vibe-Trading 与 Daily Stock Analysis 更适合当作 domain workflow patterns，而不是 general runtime。Provider credentials、memory stores、sandboxes、channels 与 scheduled jobs 应保持可独立 revoke 的边界。

快速矩阵

层	主要职责	RepoDaily 示例	架构问题
Agent runtime	Plan、tool calls、delegation、long-task lifecycle	DeerFlow / Hermes Agent	一个 runtime 是否拥有完整 task lifecycle？
Subagents / swarm	Parallel / specialized execution	DeerFlow / Vibe-Trading	Task scope、budget、failure、output 如何隔离？
Sandbox / execution	让 code/tools 远离 sensitive host state	DeerFlow / Hermes backends	Task 能访问哪些 filesystem、network、process 与 secrets？
Memory	Persist context 并检索 prior knowledge	Cognee / Hermes / DeerFlow	Memory 是 per-user、per-agent、per-project 还是 global？
Gateway / channels	把 agent session 暴露给 UI、CLI、messaging、API	DeerFlow gateway / Hermes gateway	Clients 如何 auth，sessions 如何隔离？
Domain workflow	编码 research、finance、SEO 等 specialist process	Vibe-Trading / Daily Stock Analysis	哪些步骤 deterministic，哪些依赖 LLM judgment？
Scheduler	运行 recurring briefings、audits、background jobs	Hermes cron / Daily Stock schedules	Missed run、retry、duplicate 与 stale data 如何处理？
Notifications	把 output 交付给人或 downstream systems	Hermes channels / Daily Stock delivery	Notification credential 能否触发 action，还是只读 delivery？
Provider layer	LLM、search、market data、browser、embeddings	全部 stack	Keys 是否 scoped、rotated、budgeted、environment-isolated？
Operations	Health、logs、backup、upgrade、rollback、incident response	全部 stack	能否 stop jobs、revoke keys、restore state 并解释发生了什么？

Self-hosted Agent Stack 准备度评分卡

给完整 stack 打分，不要只看 agent loop。

控制项	0 分	1 分	2 分	Owner 问题
Runtime boundary	Broad host access	Some isolation	Explicit task runtime/filesystem/network/process/secret scopes	One compromised task 能访问什么？
Memory isolation	One global store	Manual namespaces	Per-user/agent/project scopes + deletion/retention/backup	一个 tenant 能否 retrieve 另一个 tenant 的 context？
Tool policy	Generic shell/browser/filesystem	Some wrappers	Narrow tools + approvals + budgets + audit events	哪些 actions 会产生 irreversible side effects？
Provider secrets	Shared .env everywhere	Separate environments	Scoped identities + secret boundary + rotation + budget	每个 credential 由哪个 service owner 管？
Gateway security	Open local/LAN API	Auth only	Auth + session isolation + origin policy + rate limits + kill switch	谁能 start/resume/steer session？
Job reliability	Best-effort scripts	Basic retries	Idempotency + retry policy + duplicate prevention + recovery	Scheduled job 半途失败后怎么办？
Observability	Console logs	Central logs	Task IDs + tool events + provider usage + errors + redaction	能否端到端重建 bad run？
Recovery	Reinstall	Manual backup	Tested config/data backup + key rotation + rollback + clean-room restore	能否不信任 compromised state 地恢复？

60 分钟 Self-hosted Agent Stack Architecture Review

在 standardize runtime 或授予 persistent privileged access 前运行。

0–10 分钟：画出 stack

Map gateway、runtime、sandbox、tools、memory、scheduler、domain services、providers、DB 与 notification channels。

成功标准每个 component、credential flow 与 network boundary 都有 owner。

10–20 分钟：追踪一个 task

从 client identity 到 planning、tool calls、memory R/W、artifacts、notification 与 logs。

成功标准团队能解释 authority 与 data 在哪里跨边界。

20–30 分钟：检查 secrets/tools

列出每个 service/execution context 可访问的 credentials 与 privileged tools。

成功标准没有 component 拥有无必要的 broad secrets/actions。

30–40 分钟：攻击 isolation

测试 cross-session memory、sandbox escape assumptions、unauthorized gateway clients、wrong-scope tool calls 与 stale jobs。

成功标准Stack 在 external side effect 前 fail closed。

40–50 分钟：测试 operations

Stop task、restart service、retry failed job、rotate provider key、restore memory/config backup 并检查 logs。

成功标准常见 failure 有 deterministic path。

50–60 分钟：选择 minimum stack

从第一版 production design 移除不必要的 agents、gateways、memory systems、tools、providers 与 schedules。

成功标准Initial architecture 足够小，团队能 own 与 recover。

Self-hosted Agent Architecture Decision Flow

先定义 job：general research/coding agent、persistent personal agent、shared memory service、domain research workspace 或 scheduled intelligence pipeline。
选择 runtime boundary：host、containers、SSH、ephemeral sandboxes，还是 serverless/remote execution backends。
把 privileged tools 与 conversational state 分开。列出 shell、filesystem、browser、network、database、container、finance 与 notification actions，然后缩小 scope 与 approval requirements。
把 memory 当独立 data system 设计：source ingestion、namespaces、retention、deletion、backup、model/embedding dependencies、tenant separation 与 retrieval evidence inspection。
Gateway 与 runtime 分开设计：auth clients、isolate sessions、browser-facing flow 做 origin validation、限制 message size/rate，并提供 emergency stop path。
把 domain workflow 拆成 deterministic stages 与 LLM judgment stages；保存 raw data、intermediate artifacts、prompts/config、tool results 与 final outputs。
Provider identities 按 service 与 environment 分配；不要让每个 component 继承全部 LLM、search、browser、market-data、messaging 与 DB credentials。
定义 lifecycle：startup dependencies、health checks、scheduled runs、retry policy、duplicate prevention、stale cleanup、upgrade order、migration tests 与 graceful shutdown。
增加 autonomy 前先证明 recovery：revoke 一个 provider key、stop runaway task、从 backup restore memory、从 clean state rebuild runtime，并检查 logs 有用但不泄露 secrets。

场景表

场景	推荐起始架构	原因	主要风险
Team research/coding agent	DeerFlow-style runtime + isolated sandbox + scoped memory + authenticated gateway	Broad runtime capabilities 适合 long-horizon research/code	Sandbox、shell、file-write 与 provider-key exposure
Persistent personal assistant	Hermes-style always-on agent + personal memory + channels + cron + remote backend	Cross-session learning 与 messaging presence 是核心	Channel identity、autonomous skill growth 与 long-lived credentials
Shared memory for multiple agents	Agent runtimes + separate Cognee-style memory control plane	Memory lifecycle 与 tenant boundaries 独立演进	Namespace leakage、retention mistakes、model/embedding drift
Quant research workspace	Vibe-Trading-style runtime + market data + backtest + bounded connectors + audit ledger	Specialized tools 与 deterministic evaluation 比 generic chat 更重要	Financial loss、data quality、lookahead leakage、connector permissions
Daily market intelligence briefing	Daily Stock Analysis-style scheduler + ETL/research pipeline + dashboard + notifications	Recurring report 更像 pipeline problem	Data drift、duplicate jobs、stale reports、over-trust
Small internal automation	One narrow agent service + minimal memory + explicit tools + scheduler	避免 unnecessary multi-agent/gateway complexity	Ownership 与 recovery 不清楚前过度架构
Multi-tenant SaaS agent	Gateway + tenant-isolated jobs + isolated memory namespaces + centralized policy/audit	每层都需要 user separation	Cross-tenant data/tool leakage 与 shared-secret blast radius
High-risk privileged automation	Human-approved broker service + disposable execution + immutable logs	Planning 与 irreversible execution 分离	Prompt/tool compromise 造成 host/external side effects

架构风险检查表

Monolithic agent container

Runtime、browser、shell、memory DB、provider keys、messaging credentials 与 host mounts 全塞进一个 container，会形成巨大 blast radius。

Global memory

没有 user/agent/project/retention boundaries 的 shared knowledge store 会跨 task/tenant 泄露 sensitive context。

Tool capability inflation

General shell、filesystem、browser、arbitrary fetch、DB、broker、container control 会把 prompt compromise 变成 operational compromise。

Gateway equals runtime

Public/LAN gateway 不应自动继承 runtime 的全部 privilege；session admission 与 privileged execution 是两个独立决策。

Autonomous skill accumulation

Self-created/imported skills 会变成 persistent executable policy，需要 provenance、review、tool constraints 与 disable/rollback。

Scheduler without idempotency

Recurring jobs 在缺少 retry/overlap design 时会重复 notifications、reports、trades、writes 或 API spend。

Provider-key sprawl

Runtime、memory、search、browser、messaging 与 domain connectors 共用一个 .env，会让单组件 compromise 扩散到全 stack。

No clean-room recovery

Compromise 后原样恢复 mutable state，可能重新带回 malicious skills、poisoned memory、unsafe config 或 leaked credentials。

参考架构模式

Pattern A：General agent workspace

Authenticated gateway → agent runtime → per-task sandbox → narrow tools → scoped memory。默认不把 provider keys 与 host mounts 放进 sandbox。

Pattern B：Personal always-on agent

Messaging gateway → personal identity → runtime → user-scoped memory → cron → remote/ephemeral execution。Notification credentials 与 privileged tools credentials 分离。

Pattern C：Domain intelligence pipeline

Scheduler/event → deterministic data collection → agent analysis → evidence/artifact store → review gate → dashboard/notification。保留 raw inputs 与 intermediate outputs。

Memory as a service

通过 remember/recall/forget/improve-style contract 或其他 narrow memory API，让 runtime replacement 不需要同时迁移所有 agent integration。

Brokered privileged tools

Shell、browser、container、finance 或 production actions 放在 narrow broker 后，统一验证 scope、identity、budget、approval 与 audit metadata。

Clean-room recovery bundle

Reviewed config、memory exports、domain data、schemas、audit logs 与 ephemeral runtime state、caches、unreviewed generated skills 分开备份。

FAQ

面向设计 self-hosted agent infrastructure 团队的简短回答。

我需要 multi-agent runtime 吗？

大多数 first deployment 不需要。只有当 task 真正 parallel/specialized，并且能独立观察 budget、failure 与 output quality 时，再使用 subagents 或 swarms。

Memory 应该放在 agent runtime 内吗？

小型个人部署可以集成；多 agents、多 tenants、retention 或 audit requirements 较强时，应评估 separable memory layer。

Docker 足够 sandbox agent tools 吗？

不一定。真实边界取决于 mounts、capabilities、network、runtime sockets、secrets 与 host integration；高风险 task 更适合 disposable/remote environment。

Agent runtime 与 domain workflow 有什么不同？

Runtime 提供 general planning、tools、memory、execution mechanics；domain workflow 编码特定领域的 data sources、deterministic stages、evaluation rules、reports 与 controls。

应该备份什么？

备份 reviewed config、memory/knowledge exports、schemas、domain datasets、approved skills 与 audit evidence；caches、temporary sandboxes 与未 review generated state 默认可丢弃。

第一个 production control 应该是什么？

可靠 stop path。团队应能 halt scheduled jobs/active tasks、revoke provider credentials、disable privileged tools，然后再增加 autonomy。

Sources

Feedback

这页是否帮助你做出决定？

匿名反馈只用于判断内容是否真正有用。

报告过期或缺失的证据