Update nexus wiki content
This commit is contained in:
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: "Backend Architect with Memory"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
tags: [the-agency, engineering, multi-agent, memory, mcp]
|
||||
date: 2026-05-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
@@ -11,19 +11,21 @@ date: 2026-04-26
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：具备持久记忆能力的后端架构师 AI Agent 设计规范，专注于可扩展系统设计、数据库架构、API 开发与云基础设施
|
||||
- 问题域：如何构建一个能够跨会话保留架构决策、系统设计和技术约束记忆的 AI 后端架构专家
|
||||
- 方法/机制：基于 MCP Memory 集成框架，在会话开始时检索相关上下文，完成交付物后主动记忆，跨 Agent 交接时自动传递上下文
|
||||
- 结论/价值：解决多 Agent 协作中重复讨论已做决策、交接信息丢失的问题，提升 AI 架构师的实际工程价值
|
||||
- 方法/机制：基于 MCP Memory 集成框架，在会话开始时检索相关上下文，完成交付物后主动记忆，跨 Agent 交接时自动传递上下文，QA 失败时自动回滚到已知良好状态
|
||||
- 结论/价值：解决多 Agent 协作中重复讨论已做决策、交接信息丢失的问题，通过 Rollback 机制实现安全的失败恢复
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 后端架构师应在会话启动时主动检索项目相关的历史架构决策，防止重复讨论
|
||||
- 架构决策（选型数据库、定义 API 契约、选择通信模式）应以标签形式持久化，供未来会话和其他 Agent 查找
|
||||
- 交付物（Schema、API 规范、架构文档）完成后应主动记忆并标记接收方，确保下游 Agent 无需手动复制粘贴
|
||||
- 遇到 QA 失败或错误决策时，应检索上一个已知良好状态并回滚，而非手动撤销变更链
|
||||
- 标签一致性是记忆召回可靠工作的前提：每个记忆使用 Agent 名称和项目名称作为标签
|
||||
|
||||
## Key Quotes
|
||||
> "When you start a session, recall relevant context from previous sessions. Search for memories tagged with 'backend-architect' and the current project name." — 会话启动时的记忆召回机制
|
||||
> "When you make an architecture decision — choosing a database, defining an API contract, selecting a communication pattern — remember it with tags including 'backend-architect', the project name, and the topic." — 架构决策的持久化规范
|
||||
> "This prevents re-litigating decisions that were already made." — 记忆系统的核心价值
|
||||
> "When you complete a deliverable (a schema, an API spec, an architecture document), remember it tagged for the next agent in the workflow." — 交付物的下游 Agent 标记规范
|
||||
> "When you receive a QA failure or need to recover from a bad decision, search for the last known-good state and roll back to it." — Rollback 回滚机制
|
||||
|
||||
## Key Concepts
|
||||
- [[MicroservicesArchitecture]]：微服务架构，支持水平扩展和独立部署，是 Backend Architect 默认推荐的架构模式
|
||||
@@ -33,15 +35,26 @@ date: 2026-04-26
|
||||
- [[DatabaseIndexing]]：数据库索引优化，用于实现子 100ms 平均查询性能
|
||||
- [[CircuitBreaker]]：断路器模式，Backend Architect 实现系统可靠性和优雅降级的核心机制
|
||||
- [[DefenseInDepth]]：深度防御策略，Security-First Architecture 的核心原则
|
||||
- [[MemoryTagging]]：标签化记忆持久化策略——每个记忆使用 Agent 名称 + 项目名 + 主题标签（如 `database-schema`/`api-design`/`auth-strategy`）三重标签，确保 recall 可靠
|
||||
- [[Rollback]]：回滚机制——QA 失败时检索最近良好检查点并恢复到已知良好状态，而非手动撤销变更链
|
||||
|
||||
## Key Entities
|
||||
- Backend Architect：主 Agent，专门负责系统架构和服务器端开发，特点：战略思维、安全导向、可扩展性优先、可靠性至上
|
||||
- Frontend Developer：下游接收方 Agent，接收 Backend Architect 提供的 API 规范
|
||||
- QA Agent：质量保障 Agent，在失败时触发记忆回滚机制
|
||||
- Sprint Prioritizer：上游输入方 Agent，提供待开发功能的优先级排序
|
||||
|
||||
## Connections
|
||||
- [[AgentsOrchestrator]] ← coordinates ← [[BackendArchitectWithMemory]]
|
||||
- [[MCPBuilderAgent]] ← enables ← [[BackendArchitectWithMemory]]（MCP Memory 集成）
|
||||
- [[SprintPrioritizer]] → outputs sprint plan → [[BackendArchitectWithMemory]]（通过 MCP Memory Server recall）
|
||||
- [[UXResearcher]] → outputs research brief → [[BackendArchitectWithMemory]]（通过 MCP Memory Server recall）
|
||||
- [[BackendArchitectWithMemory]] → stores API spec → [[FrontendDeveloper]]（通过 MCP Memory Server recall）
|
||||
- [[BackendArchitectWithMemory]] ← rollback ← [[TestingRealityChecker]]（QA 失败触发）
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突内容
|
||||
- 与 [[engineering-software-architect]] 的设计哲学存在微妙张力：
|
||||
- 冲突点：架构决策记录方式
|
||||
- 当前观点（Backend Architect with Memory）：通过 MCP Memory 标签化快照持久化，支持跨 Agent 召回和自动回滚
|
||||
- 对方观点（Software Architect）：通过 ADR（Architecture Decision Record）标准化文档记录，侧重人类可读的权衡分析
|
||||
- 协调方案：两者互补——ADR 文档供人类阅读和团队共享，MCP Memory 快照供 Agent 自动化召回；Backend Architect 可同时使用两者作为不同场景的工具
|
||||
|
||||
Reference in New Issue
Block a user