Auto-sync: 2026-04-26 12:02

wiki/sources/engineering-software-architect.md

@@ -0,0 +1,58 @@
+---
+title: "Software Architect Agent Personality"
+type: source
+tags: [agent-personality, software-architecture, system-design, engineering]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-software-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：软件架构与系统设计 Agent 的角色定义，专注于设计可维护、可扩展、符合业务领域的系统架构
+- 问题域：架构决策、模式选择、技术权衡、系统演进
+- 方法/机制：领域驱动设计（DDD）、边界上下文（bounded contexts）、架构决策记录（ADR）、C4 模型
+- 结论/价值：为 AI Agent 提供系统思维框架，强调权衡分析优先于最佳实践、领域优先于技术
+
+## Key Claims（用中文描述）
+- 最佳架构是团队能够实际维护的架构：架构不应过度设计，必须匹配团队能力
+- 每个抽象必须有复杂度理由：避免架构宇航员式的过度设计
+- 权衡优先于最佳实践：命名所放弃的，而非仅描述所获得的
+- 领域优先、技术其次：理解业务问题，再选工具
+- 可逆性很重要：优先选择易变更的决策，而非"最优"决策
+- 记录决策，而非仅记录设计：ADR 捕捉 WHY，而非 WHAT
+
+## Key Quotes
+> "Designs systems that survive the team that built them. Every decision has a trade-off — name it." — 核心设计哲学
+
+> "No architecture astronautics — Every abstraction must justify its complexity." — 关键规则 1
+
+> "Domain first, technology second — Understand the business problem before picking tools." — 关键规则 3
+
+> "Reversibility matters — Prefer decisions that are easy to change over ones that are 'optimal'." — 关键规则 4
+
+## Key Concepts
+- [[Bounded Contexts]]：领域驱动设计中划分业务边界的核心概念
+- [[Trade-off Analysis]]：架构决策中命名权衡而非仅列举优点的分析方法
+- [[Architecture Decision Record (ADR)]]：记录架构决策上下文、选项和理由的标准化模板
+- [[Modular Monolith]]：适合小型团队、不清晰边界的架构模式
+- [[Microservices]]：适合清晰领域、需要团队自治的架构模式
+- [[Event-Driven Architecture]]：适合松耦合、异步工作流的架构模式
+- [[CQRS]]：命令查询职责分离，适合读写不对称的系统
+- [[C4 Model]]：用四层图（C4：Context, Container, Component, Code）交流架构的标准化方法
+- [[Quality Attributes]]：可扩展性、可靠性、可维护性、可观测性等非功能需求
+
+## Key Entities
+- （本文档为通用 Agent 角色定义，未涉及特定人物、公司或产品）
+
+## Connections
+- [[BackendArchitectWithMemory]] ← shares_design_philosophy ← [[SoftwareArchitectAgent]]
+- [[WorkflowArchitect]] ← uses_ADR_pattern ← [[SoftwareArchitectAgent]]
+- [[SpecializedWorkflowArchitect]] ← architectural_decision_making ← [[SoftwareArchitectAgent]]
+
+## Contradictions
+- 与 [[UnityArchitect]] 冲突：
+  - 冲突点：架构约束与团队规模的关系
+  - 当前观点（Software Architect）：最佳架构取决于团队能力； microservices 不适合小团队
+  - 对方观点（Unity Architect）：针对特定技术平台（Unity）的架构师角色，可能倾向于选择特定技术栈而非纯权衡驱动
+  - 注：两者领域不同（通用软件架构 vs 游戏引擎架构），冲突仅为框架层面的方法论差异