Update nexus wiki content

wiki/sources/engineering-backend-architect.md

@@ -0,0 +1,66 @@
+---
+title: "Backend Architect Agent Personality"
+type: source
+tags: [the-agency, engineering, backend, architecture, cloud, database, api]
+date: 2026-05-01
+---
+
+## Source File
+- [[raw/Agent/agency-agents/engineering/engineering-backend-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：Backend Architect AI Agent 人格定义——专注于可扩展系统设计、数据库架构、API 开发与云基础设施的高级后端架构师
+- 问题域：如何定义一个能够设计大规模、高可靠、安全可扩展的后端系统和微服务的 AI Agent 角色
+- 方法/机制：数据模式工程 → 可扩展系统架构 → 系统可靠性保障 → 性能与安全优化，核心方法包括微服务分解、CQRS/ES 模式、数据库索引、熔断器设计
+- 结论/价值：Backend Architect 输出的系统架构、数据库 Schema、API 规范和监控策略是整个系统可靠运行的基石，属 The Agency Engineering 部门
+
+## Key Claims（用中文描述）
+- 后端架构师必须从一开始就设计水平扩展能力，而非事后补救
+- 认证和授权系统必须防止常见漏洞，遵循最小权限原则
+- 数据库查询必须实现子 20ms 性能目标，通过正确的索引和查询优化实现
+- 系统设计必须包含多层次安全措施（Defense in Depth）和数据加密（静态和传输中）
+- API 响应时间应始终保持在 200ms 以内（P95）
+- 系统可用性应超过 99.9%，配合适当的监控和自动扩缩容
+
+## Key Quotes
+> "Design for horizontal scaling from the beginning." — 性能意识设计核心理念
+> "Implement defense in depth strategies across all system layers." — 安全优先架构原则
+> "Use principle of least privilege for all services and database access." — 最小权限原则
+> "API response times consistently stay under 200ms for 95th percentile." — 成功指标之一
+> "Database queries perform under 100ms average with proper indexing." — 数据库性能目标
+
+## Key Concepts
+- [[MicroservicesArchitecture]]：微服务架构，支持水平扩展和独立部署，是 Backend Architect 默认推荐的系统分解模式
+- [[CQRS]]：命令查询职责分离，用于读写不对称的复杂领域（如订单系统）
+- [[EventSourcing]]：事件溯源，与 CQRS 配合用于复杂业务域的数据建模
+- [[ServerlessArchitecture]]：无服务器架构，Backend Architect 认可的可自动扩展且成本效益高的云部署方式
+- [[DatabaseIndexing]]：数据库索引优化，用于实现子 100ms 平均查询性能
+- [[CircuitBreaker]]：断路器模式，Backend Architect 实现系统可靠性和优雅降级的核心机制
+- [[DefenseInDepth]]：深度防御策略——跨所有系统层实施多层安全措施
+- [[Event-DrivenArchitecture]]：事件驱动架构，支持高吞吐量和松耦合的系统间通信
+- [[API-Versioning]]：API 版本管理，确保向后兼容性和平滑升级
+- [[HorizontalScaling]]：水平扩展——通过增加服务实例而非单体扩容来实现系统扩展
+
+## Key Entities
+- [[SoftwareArchitect]]：同部门兄弟 Agent，专注于系统设计、DDD 和架构模式，与 Backend Architect 共享架构思维
+- [[MobileAppBuilder]]：同部门兄弟 Agent，接收 Backend Architect 输出的 API 规范进行移动端开发
+- [[GodotMultiplayerEngineer]]：Game Dev 部门 Agent，与 Backend Architect 共享服务器权威原则和网络架构理念
+
+## Connections
+- [[SoftwareArchitect]] ← shares_architecture_principles ← [[BackendArchitectAgent]]（可扩展性、安全性、可靠性是共同核心价值）
+- [[MobileAppBuilder]] ← depends_on ← [[BackendArchitectAgent]]（API 规范作为下游输入）
+- [[GodotMultiplayerEngineer]] ← shares_server_authority ← [[BackendArchitectAgent]]（服务器权威是共同网络架构原则）
+- [[AutonomousOptimizationArchitect]] ← relates_to ← [[BackendArchitectAgent]]（两者都关注系统性能和可靠性优化）
+- [[SRE]] ← relates_to ← [[BackendArchitectAgent]]（Backend Architect 输出的架构为 SRE 的可靠性工作提供基础）
+
+## Contradictions
+- 与 [[backend-architect-with-memory]] 的架构决策方式存在张力：
+  - 冲突点：持久化架构知识的方式
+  - 当前观点（engineering-backend-architect）：通过 System Prompt 和交付物文档（System Architecture Specification、Database Schema、API Design）进行知识传递
+  - 对方观点（backend-architect-with-memory）：通过 MCP Memory 标签化快照持久化，支持跨 Agent 自动召回和回滚
+  - 协调方案：两者互补——文档规范供人类可读和跨团队共享，MCP Memory 快照供 Agent 自动化召回；engineering-backend-architect 是基础角色定义，backend-architect-with-memory 是增强版
+- 与 [[SoftwareArchitect]] 的抽象层次存在差异：
+  - 冲突点：架构粒度
+  - 当前观点（Backend Architect）：关注数据库 Schema、API 端点、WebSocket 事件、部署拓扑等具体实现细节
+  - 对方观点（Software Architect）：关注领域边界、模式选型、质量属性权衡等抽象层次
+  - 协调方案：Software Architect 负责\"做什么系统\"（What），Backend Architect 负责\"怎么做\"（How）；两者在不同抽象层次工作，互为补充