8 篇文章带有标签 “design”

一套面向 Agent 应用设计者的系统化设计原则、架构模式与实战指南。

基于对 WorkBuddy（CodeBuddy Code）工作空间源码、系统提示词、文档与架构的深度分析提炼而成。

目录

1. 概述：从 Chatbot 到 Agent 的范式跃迁
2. 原则一：闭环执行架构
3. 原则二：人格化身份体系
4. 原则三：分层记忆系统
5. 原则四：纵深防御安全模型
6. 原则五：渐进式能力扩展
7. 原则六：多模态工作模式
8. 原则七：上下文精细管理
9. 原则八：可组合的工具哲学
10. 系统架构全景图
11. 可复用的设计模式清单
12. 设计决策框架
13. 常见反模式

1. 概述：从 Chatbot 到 Agent 的范式跃迁

1.1 Chatbot 和 Agent 的本质区别

维度	Chatbot	Agent
核心能力	理解并回答	理解、计划、执行、验证
与环境的交互	被动接收文本	主动感知文件系统、网络、工具
输出的性质	文本回答	实际行动（文件变更、API 调用、部署）
正确性保障	依赖训练数据	通过执行测试、编译、对比等方式自我验证
会话生命周期	一问一答，无持续性	跨多轮持久化，可中断恢复
用户角色	提问者	协作者/监督者

设计 Agent 系统，首先要完成这个认知跃迁：Agent 不是"更强的 Chatbot"，而是一种全新的交互范式。

1.2 Agent 设计的核心张力

在设计 Agent 系统时，始终面临以下四对核心张力：

WorkBuddy 介绍

AI 专家团 全场景办公

WorkBuddy 是全能 AI 工作台，一人指挥，全行业专家执行，从策略到交付一站搞定

免部署·安装即用 ｜ 多专家·多模型协同 ｜ 全平台·桌面 / 主流 IM / 小程序

100+ 领域专家组成你的虚拟团队，运营、设计、数据、开发等全角色场景覆盖

一句话指令自主规划并交付完整结果

多专家并行协作，一个人顶一支团队

MCP 生态 + 自定义 Skills，能力无限扩展

设计系统（Design System）

• 场景：设计系统
• 模型：Deepseek-V4-Flash

输入（宫崎骏的太空之城风格设计系统）

帮我建立一套完整的 Design System，包含颜色体系、字体层级、间距规则和基础组件规范文档，风格为宫崎骏的太空之城

输出

基于 /Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked 逆向分析 WorkBuddy Desktop v5.2.5 + CodeBuddy CLI v2.106.4 | 腾讯出品

一、整体架构概览

原文：A field guide to Claude Fable 5: Finding your unknowns 作者：Thariq Shihipar（Anthropic 技术团队成员）

在使用 Claude Code 时，我常常想起地图与领土之间的区别。

地图，即待完成工作的表征，是我的提示词、技能和上下文——是我提供给 Claude 的东西。领土，则是工作需要实际发生的地方：代码库、现实世界、真实的约束条件。

地图与领土之间的差距，就是我所说的未知（unknowns）。当 Claude 遇到一个未知时，它需要根据对我意图的最佳猜测来做出决策。工作量越大，Claude 可能遇到的未知就越多。

Claude Fable 是我遇到的第一个模型，其工作质量的瓶颈在于我澄清未知的能力。

重要的是，仅仅提前规划并不总是足够的。你可能会在深入实现时发现未知，或者你的未知可能指向一个事实：你其实应该用完全不同的方式来解决问题。

我发现，使用 Fable 工作是一个迭代过程——在实现之前、之中和之后，不断发现自己的未知。

认识你的未知

你的未知是什么？当我带着问题来找 Claude 时，我倾向于将其分解为四种类型：

• 已知的已知（Known Knowns）：这本质上就是我的提示词中的内容。我告诉智能体我想要什么？
• 已知的未知（Known Unknowns）：我还有什么没搞清楚的，但我已经意识到我还没搞清楚？
• 未知的已知（Unknown Knowns）：有哪些事情如此显而易见，以至于我永远不会写下来，但看到时却能认出来？
• 未知的未知（Unknown Unknowns）：我完全没有考虑过什么？有哪些知识是我不知道自己不知道的？我知道某件事可以做得多好？

官网定位一句话：将文字、草图、截图、语音指令，一键生成 Web / 移动端高保真界面、可交互原型与可直接投入开发的前端代码，打通「灵感→设计→开发」完整工作流。 访问入口：stitch.withgoogle.com

🚀 Stitch：从想法到落地

Stitch 提倡“设计先行，边做边改”。告别面对空白页的焦虑，无需追求一步到位，通过不断迭代轻松产出优秀设计。

1. 极简起步：三步提示词公式

写下你的初始想法，无需死磕细节，给一个大概的“配方”即可生成：

• [想法] 是什么 + [主题] 风格氛围 + [内容] 核心板块。

2. 精准迭代：每次只改动一点

生成初稿后，构思才真正开始。

• 小步快跑： 每次锁定一个问题，用具体指令（配合 UI/UX 词汇）让 AI 修改。
• 全局调整： 善用“编辑主题”一键更换深浅模式、颜色和字体。

3. 验证与交付：从静态到上线

• 动效测试： 一键生成交互式“原型”，测试按钮悬停、文本输入等真实体验。
• 多端导出： 导出 HTML 和图片包。HTML 是万能资产，可借助大模型轻松转换为 React、Vue 或手机原生代码（Flutter/SwiftUI 等）。

💡 核心寄语： 别想太多，先生成，再优化。持续构思，直到满意！

• Everything you need to know

欢迎来到 Stitch。今天您将学习如何从设计切入并专注于概念构思。关键在于不要过度思考。

DESIGN.md是什么？

每个项目都有自己的视觉标识：颜色、字体、间距、组件样式。传统上，这些内容存储在 Figma 文件、品牌 PDF 或设计师的脑海中。AI 智能体无法读取这些格式。

DESIGN.md 改变了这一点。 它是一个纯文本设计系统文档，人类和智能体都可以阅读、编辑和执行。可以将其视为 AGENTS.md 的设计对应物：

文件	阅读者	定义内容
README.md	人类	项目是什么
AGENTS.md	编码智能体	如何构建项目
DESIGN.md	设计智能体	项目应该长什么样、什么感觉

它能给你带来什么

当像 Stitch 这样的设计智能体读取你的 DESIGN.md 时，它生成的每个屏幕都遵循相同的视觉规则：你的调色板、你的排版、你的组件模式。没有它，每个屏幕都是孤立的；有了它，它们看起来属于同一个产品。

DESIGN.md 是一个活的产物，而不是静态配置文件。它随着你的设计演变而演变。智能体生成它，你完善它，并在迭代过程中重新应用到屏幕上。

在底层，每个 DESIGN.md 都有两层：YAML 前置元数据包含机器可读的设计令牌（精确的十六进制值、字体属性、间距尺度）和Markdown 正文提供人类可读的设计原理说明。令牌为智能体提供精确值。散文告诉它们为什么这些值存在。完整的格式请参阅规范。

设计理念

DESIGN.md 规范是一个基础，而非规定。

• DESIGN.md

一种用于向编码智能体描述视觉识别系统的格式规范。DESIGN.md 让智能体对设计系统拥有持久、结构化的理解。

格式

DESIGN.md 文件将机器可读的设计令牌（YAML 前置元数据）与人类可读的设计原理（Markdown 正文）相结合。令牌为智能体提供精确值，正文则解释这些值为何存在以及如何使用。

---
name: Heritage
colors:
  primary: "#1A1C1E"
  secondary: "#6C7278"
  tertiary: "#B8422E"
  neutral: "#F7F5F2"
typography:
  h1:
    fontFamily: Public Sans
    fontSize: 3rem
  body-md:
    fontFamily: Public Sans
    fontSize: 1rem
  label-caps:
// ...

读取此文件的智能体将生成一个 UI：Public Sans 字体的深墨标题、温暖石灰石背景，以及波士顿陶土色的行动号召按钮。

快速开始

对照规范验证 DESIGN.md，捕获损坏的令牌引用、检查 WCAG 对比度比率，并输出结构化发现——所有结果均以智能体可处理的 JSON 格式呈现。