程序员 Agent 与设计师 Agent：两种 Runtime Profile 的架构差异

可以。这里最重要的一个设计原则是：“程序员 Agent”和“设计师 Agent”不应该只是换一份 system prompt，而应该是两套不同的 Agent Runtime Profile。

它们可以共享同一个 Agent OS，但：

• 程序员的核心工作对象是 代码、仓库、测试、运行环境
• 设计师的核心工作对象是 视觉资产、设计系统、页面结构、交互状态、设计稿

所以我会设计成：

下面分别展开。

---

一、共同底座：Shared Agent OS

我不会分别造两个完全不同的系统。

底层共用：

核心实体：

AgentDefinition
AgentInstance
Task
Workspace
Artifact
Capability
Memory
Event
Approval
Run

区别只在：

也就是说：

设计师：

这是最干净的设计。

---

二、程序员 Agent：理想架构

我会把它设计成一个：

Repository-centric Software Engineering Agent

而不是聊天机器人。

整个中心是：

Repository + Workspace + Task

---

1. 程序员 Agent 总架构

这里最关键的一点：

程序员 Agent 操作的是 Workspace，而不是裸 filesystem。

---

2. Programmer Workspace

建议定义：

interface CodeWorkspace {
  id: string;

  repository: Repository;
  branch: string;

  filesystem: FileSystem;
  sandbox: Sandbox;

  languageServers: LSP[];

  git: GitClient;

  runtime: RuntimeEnvironment;

  dependencyGraph: DependencyGraph;
}

里面要包含：

这意味着 Agent 看到的不只是：

文件

而是：

Software System

---

3. Context Engine：不要靠 grep + read 硬撑

程序员 Agent 的 Context Engine 应该是专用的。

输入：

“修复登录后偶尔出现 401 的问题”

Context Engine 应该构造：

所以应该存在：

这比单纯：

grep -R "login"

高一个层次。

---

4. 程序员 Agent 的模型角色

这里我非常建议 Multi-model。

不是：

一个最强模型干所有事情

而是：

可以定义：

type ProgrammerModelRole =
  | "explorer"
  | "planner"
  | "coder"
  | "reviewer"
  | "debugger"
  | "summarizer";

这样成本会合理很多。

---

5. 不应该只有一个 Programmer Agent

真正理想状态：

对于复杂任务：

---

6. Programmer Artifact

千万不要让 Agent 之间只交换聊天。

核心 artifact：

interface CodePlanArtifact {
  hypothesis: string[];
  files: string[];
  changes: ChangeProposal[];
  validation: ValidationPlan[];
}

interface PatchArtifact {
  diff: string;
  filesChanged: string[];
  rationale: string;
}

interface TestArtifact {
  command: string;
  passed: number;
  failed: number;
  output: string;
}

interface ReviewArtifact {
  issues: ReviewIssue[];
  approved: boolean;
}

最终 task：

---

7. Programmer 最重要的是 Verifier

程序员 Agent 的可靠性很大程度不是来自 Model。

而是：

Verifier

完整流水线：

也就是说：

LLM proposes
Computer proves

尽量如此。

---

8. 程序员的工具体系

应该分层：

通过 MCP 暴露。

但是不同 Agent capability 不同。

Explorer：

Coder：

Reviewer：

Deploy Agent：

artifact read
CI
deployment

---

9. 程序员 Memory

程序员 Memory 不应该太“人格化”。

它应该偏：

Engineering Knowledge

我会拆：

例如：

其中：

本身也是重要 memory source。

---

10. Programmer 的完整执行过程

用户：

给我们的支付模块增加退款功能。

应该变成：

这才是“程序员”。

---

三、设计师 Agent：不能照搬 Programmer 架构

设计师的核心不是：

文件 → patch → test

而是：

所以 Designer Agent 更适合：

Artifact-centric + Multimodal + Render-Verify Loop

---

11. Designer Agent 总架构

核心循环完全不同：

---

12. Designer Workspace

设计 Workspace 应该定义成：

interface DesignWorkspace {
  designDocument: DesignDocument;

  designSystem: DesignSystem;

  assets: AssetLibrary;

  references: ReferenceLibrary;

  browser: BrowserEnvironment;

  renderer: RenderEngine;

  viewportProfiles: ViewportProfile[];
}

核心不是：

filesystem

而是：

Design Graph

比如页面：

Designer Agent 应该理解：

---

13. 设计系统要成为 First-Class Context

程序员主要读取：

AGENTS.md
codebase

设计师主要应该读取：

形成：

例如：

Agent生成的东西必须遵守这些约束。

---

14. Designer 的 Memory 更偏“审美与用户理解”

Designer Memory 应该包含：

例如：

这些对于设计师 Agent 比：

“用户喜欢 TypeScript”

重要得多。

---

15. Designer Agent 最重要的是 Multimodal Context

Programmer：

text → text/code

Designer：

全部都可能成为输入。

因此：

模型必须具备：

vision
layout reasoning
visual comparison

---

16. Designer 不应该只有一个“设计模型”

我会拆：

还有：

Design System Agent

专门检查：

---

17. Designer Artifact 比程序员更多样

核心 artifact：

DesignBriefArtifact

UserFlowArtifact

WireframeArtifact

VisualDirectionArtifact

DesignFrameArtifact

PrototypeArtifact

DesignReviewArtifact

例如完整 task：

---

18. Designer 最重要的 Tool 不是 image generation

很多人做“AI Designer”的第一反应是：

image model

其实不对。

真正有用的 Designer Agent 应该拥有：

Image Generation 只是其中一个能力。

---

19. Designer 的核心循环：Render → Critique

这是和程序员最大的差别之一。

程序员：

设计师：

也就是：

没有 render loop 的 Designer Agent 很难真正成为设计师。

---

20. Designer Verifier 是什么？

没有：

npm test

但依然可以构建大量 verifier。

Deterministic

Visual

Interaction

所以：

---

21. Designer 的“Compiler”其实是 Renderer

可以做一个非常有意思的类比：

程序员	设计师
Source Code	Design Model
Compiler	Renderer
Runtime	Browser / Device
Test	Visual/UX Verification
AST	Design Tree
LSP	Design Graph
Dependency Graph	Component Graph
Git Diff	Visual Diff
Code Review	Design Critique
Build Artifact	Rendered Prototype

所以：

对应：

这个类比非常有价值。

---

22. Design Tree ≈ AST

例如：

不要只让 Agent看到 screenshot。

它还应该看到：

{
  "type": "Grid",
  "columns": 3,
  "gap": 24,
  "children": [...]
}

这样 Agent 可以结构化修改：

change gap 24 → 32

而不是：

“重新生成整个图片”

这正好对应 coding：

AST edit
vs
rewrite whole file

---

23. Designer 也需要类似 Patch 的东西

比如：

而不是：

重新生成整张页面

否则：

不可控
不稳定
难 review

所以我会定义：

interface DesignPatch {
  nodeId: string;
  property: string;
  oldValue: unknown;
  newValue: unknown;
}

---

24. 设计师最需要“双视角”

这是非常值得实现的。

Designer Agent应该同时看到：

Semantic Tree
      +
Rendered Screenshot

因为：

Tree

告诉它：

结构
组件
约束

Screenshot告诉它：

真实视觉结果

就像程序员同时需要：

source code
+
runtime behavior

结构：

---

25. Programmer 和 Designer 还应该能够协作

这是整个系统真正有意思的地方。

比如用户说：

做一个新的 SaaS Dashboard。

理想情况不是 Designer 完后人工交给 Programmer。

而是：

---

26. Designer → Programmer 不应该传截图

应该传：

Design Specification Artifact

例如：

interface UIComponentSpec {
  name: string;

  hierarchy: Node[];

  tokens: DesignToken[];

  responsiveRules: Rule[];

  interactions: Interaction[];

  states: State[];

  assets: AssetReference[];
}

Programmer 收到：

而不是：

请照这个 PNG 写。

这是非常大的区别。

---

27. 两者共享 Design System / Component System

例如：

定义一个 canonical component：

这样 Designer 和 Programmer 操作的是：

同一个 Component Identity

---

28. 最理想的是建立“Design-Code Graph”

这我非常推荐。

例如：

这样：

Designer 修改：

Button radius 8 → 12

系统知道影响：

47 screens
1 React component
12 visual snapshots

然后可以创建：

Programming Task

这才是真正的 Agent-native 产品开发。

---

29. 两类 Agent 的差异可以总结成这张表

	程序员	设计师
核心对象	Repository	Design Document
Workspace	Code Workspace	Design Workspace
Structured Representation	AST / LSP	Design Tree
Output	Patch	Design Patch
Runtime	Sandbox	Renderer/Browser
Verification	Compile/Test	Render/Critique
History	Git	Design Versions
Knowledge	Architecture	Design System
Memory	Engineering Decisions	Brand/UX Decisions
Main Tools	shell/git/LSP	Figma/browser/render
Model	Coding/Reasoning	Vision/Design/Reasoning
Deterministic verifier	强	中等
Visual verifier	辅助	核心

---

30. 如果把两者放进同一个“AI 公司”

我最终会这么设计：

这里其实就已经开始接近：

AI-native Software Company Runtime

---

31. 如果你是个人开发，我建议先这样实现

不要一开始做 20 个 Agent。

Programmer V1

只做：

底层：

---

Designer V1

只做：

Design Director
UI Designer
Critic

底层：

再定义两个核心中间格式：

DesignArtifact
CodeArtifact

---

32. 然后最值得做的是统一 Artifact Protocol

比如：

interface Artifact {
  id: string;
  type: string;

  taskId: string;

  createdBy: AgentId;

  version: number;

  dependencies: ArtifactId[];

  content: unknown;
}

具体：

所有 Agent 都围绕：

Artifact Graph

工作。

这会比围绕：

Conversation

高级非常多。

---

33. 如果让我给这两个 Agent 定义一句话

程序员 Agent：

设计师 Agent：

而共同底座是：

这就是我会采用的整体设计。

更进一步，如果你的最终目标是做一个真的能开发完整产品的 AI Team，那么我下一步不会继续加 Agent 数量，而会优先设计中间最关键的 Product Graph：把 需求 → User Flow → Design → Component → Code → Test → Release 连成一张结构化图。只要 Product Graph 建起来，程序员和设计师才不再是两个互相聊天的机器人，而是真正围绕同一个产品状态协同工作的两个智能角色。