Update nexus wiki content
This commit is contained in:
@@ -1,58 +1,50 @@
|
||||
---
|
||||
title: "Software Architect Agent Personality"
|
||||
type: source
|
||||
tags: [agent-personality, software-architecture, system-design, engineering]
|
||||
date: 2026-04-26
|
||||
tags: []
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/engineering/engineering-software-architect.md]]
|
||||
- [[Agent/agency-agents/engineering/engineering-software-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：软件架构与系统设计 Agent 的角色定义，专注于设计可维护、可扩展、符合业务领域的系统架构
|
||||
- 问题域：架构决策、模式选择、技术权衡、系统演进
|
||||
- 方法/机制：领域驱动设计（DDD）、边界上下文（bounded contexts）、架构决策记录（ADR）、C4 模型
|
||||
- 结论/价值：为 AI Agent 提供系统思维框架，强调权衡分析优先于最佳实践、领域优先于技术
|
||||
- 核心主题：AI Agent 软件架构专家人格定义——专注于系统设计、领域驱动设计、架构模式和可扩展性决策的智能体角色
|
||||
- 问题域：如何让 AI Agent 在多智能体协作中承担软件架构职责，在模块化单体与微服务之间做出权衡，并维护架构决策记录
|
||||
- 方法/机制：五步系统设计流程（领域发现→架构选型→质量属性分析→沟通风格→文档输出）；ADR 模板规范；C4 模型通信
|
||||
- 结论/价值：Software Architect Agent 通过明确约束（反架构航天员主义、权衡优先于最佳实践）确保 AI 输出的架构建议务实可落地
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 最佳架构是团队能够实际维护的架构：架构不应过度设计，必须匹配团队能力
|
||||
- 每个抽象必须有复杂度理由：避免架构宇航员式的过度设计
|
||||
- 权衡优先于最佳实践：命名所放弃的，而非仅描述所获得的
|
||||
- 领域优先、技术其次：理解业务问题，再选工具
|
||||
- 可逆性很重要：优先选择易变更的决策，而非"最优"决策
|
||||
- 记录决策，而非仅记录设计：ADR 捕捉 WHY，而非 WHAT
|
||||
- AI Agent 通过严格约束"每个抽象必须证明其复杂度"，可以避免陷入架构过度设计的陷阱
|
||||
- 在模块化单体与微服务之间选择时，团队规模和边界清晰度比技术优越性更关键
|
||||
- 架构决策记录（ADR）捕获"为什么"而非"是什么"，是 AI 协作中保持决策可追溯的关键机制
|
||||
- 领域优先、技术其次——理解业务问题再选工具，是 AI 系统设计建议可靠性的基础保障
|
||||
|
||||
## 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
|
||||
> "No architecture astronautics — Every abstraction must justify its complexity." — 核心设计原则：AI 不得产生无实际价值的过度抽象
|
||||
> "Trade-offs over best practices — Name what you're giving up, not just what you're gaining." — 架构权衡的透明性要求
|
||||
> "The best architecture is the one the team can actually maintain." — 可维护性优先于理论最优解
|
||||
|
||||
## 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]]：可扩展性、可靠性、可维护性、可观测性等非功能需求
|
||||
- [[Bounded Contexts]]：领域驱动设计中的核心概念，定义特定领域的边界，确保模型在边界内一致
|
||||
- [[ADR (Architecture Decision Records)]]：架构决策记录文档模板，捕获上下文、决策和后果，而非仅记录结果
|
||||
- [[Trade-off Matrices]]：架构权衡矩阵，用于系统性对比多个方案的取舍
|
||||
- [[Modular Monolith vs Microservices]]：模块化单体（团队规模小、边界不清晰时）与微服务（领域清晰、团队自主性要求高时）的选型对照
|
||||
- [[CQRS (Command Query Responsibility Segregation)]]：命令查询职责分离，适合读写不对称场景
|
||||
- [[Event-driven Architecture]]：事件驱动架构，适合松耦合和异步工作流场景
|
||||
- [[C4 Model]]：系统通信图模型（Context/Container/Component/Code 四层），用于在不同抽象层级与干系人沟通
|
||||
|
||||
## Key Entities
|
||||
- （本文档为通用 Agent 角色定义，未涉及特定人物、公司或产品）
|
||||
- [[C4 Model]]：由 Simon Brown 创建的系统架构可视化标准，用于在不同抽象层级进行架构沟通
|
||||
|
||||
## Connections
|
||||
- [[BackendArchitectWithMemory]] ← shares_design_philosophy ← [[SoftwareArchitectAgent]]
|
||||
- [[WorkflowArchitect]] ← uses_ADR_pattern ← [[SoftwareArchitectAgent]]
|
||||
- [[SpecializedWorkflowArchitect]] ← architectural_decision_making ← [[SoftwareArchitectAgent]]
|
||||
- [[Backend-Architect-With-Memory]] ← similar_role ← [[Software-Architect-Agent]]
|
||||
- [[Agents-Orchestrator]] ← depends_on ← [[Software-Architect-Agent]]
|
||||
- [[Workflow-Architect-Agent]] ← related_to ← [[Software-Architect-Agent]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[UnityArchitect]] 冲突：
|
||||
- 冲突点：架构约束与团队规模的关系
|
||||
- 当前观点（Software Architect）：最佳架构取决于团队能力； microservices 不适合小团队
|
||||
- 对方观点（Unity Architect）：针对特定技术平台（Unity）的架构师角色，可能倾向于选择特定技术栈而非纯权衡驱动
|
||||
- 注：两者领域不同（通用软件架构 vs 游戏引擎架构），冲突仅为框架层面的方法论差异
|
||||
- 与 [[Backend-Architect-With-Memory]] 的潜在冲突：
|
||||
- 冲突点：后端架构师是否需要持久记忆能力
|
||||
- 当前观点（Software Architect Agent）：架构师 Agent 关注设计决策和权衡，无需持久状态
|
||||
- 对方观点（Backend Architect with Memory）：架构师 Agent 需要跨会话累积上下文才能提供更准确建议
|
||||
- 协调方案：两者可互补——Memory 作为辅助数据源，Software Architect 作为推理引擎
|
||||
|
||||
Reference in New Issue
Block a user