--- 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 游戏引擎架构),冲突仅为框架层面的方法论差异