约束与分拆

AI Agent 工程化实践

一月

我想问一个问题:

模型能帮你工作,
但如何让它稳定的做好工作?

我的分享:

约束(Constraints)
→ 把"随机探索"变成"标准执行"

分拆(Decomposition)
→ 把"单点瓶颈"变成"分工协作"

约束

Constraints

大模型「完成工作」和「做好工作」是两回事

模型有能力,但缺乏场景化的标准路径

模型的局限

案例 1：aihot 中文 AI 资讯查询 Skill

定位：抓取信息生成简报的路径约束示例

把“去哪里查、按什么顺序查、怎样筛选来源”固化为执行路径

生成可直接阅读的中文 AI 简报：热点摘要 / 趋势判断 / 链接来源

中文 AI 资讯源

↓ aihot Skill 路径约束

稳定简报输出

无 Skill 时的表现

• Agent 知道可以搜索网页
• Agent 知道可以总结新闻

• 但会反复摸索:搜哪些关键词?看哪些来源?按什么格式输出?
• 每次执行可能选择不同路径
• 热点排序、来源引用和分类标准不一致

Token 消耗:约 15,000-30,000 tokens/次

有 aihot Skill 后的表现

✓ SKILL.md 明确:优先查询中文 AI 热点源与权威链接
✓ 指定输出格式:标题、摘要、影响、来源、适合人群
✓ 指定筛选标准:按新鲜度、可信度和讨论热度排序

Token 消耗:约 3,000-5,000 tokens/次

结论:
✓ 成本节省 70-80%
✓ 输出结构稳定,可复用、可追溯

案例 2:andrej-karpathy-skills

来源:github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md

定位:行为准则 Skill,教 AI 写出更干净的代码,是行为边界约束示例。

核心原则:不要假设,困惑先问清楚;写最少代码解决问题,不要过度设计。

执行边界:只改必须改的,不"顺便优化"无关代码;定义成功标准,循环验证直到通过。

价值:让 AI 写的代码更简洁、更聚焦、diff 更干净。

没有它 vs 有了它

没有 andrej-karpathy-skills:AI 可能过度设计、写一堆"以防万一"的代码,甚至顺便重构无关模块。

有了 andrej-karpathy-skills:AI 会先澄清问题,聚焦最小改动,用验证标准收敛结果。

Token 消耗对比

无 Skill
22,000

有 Skill
4,000

节省约 80%

类比：无约束 vs 有约束

厨师做菜：每次凭感觉调味 → 标准菜谱 + 配比表

新员工入职：自己摸索公司流程 → 入职手册 + 导师

模型执行任务：每次从零推理 → SKILL.md + Memory

在复杂任务时根据实际工程经验统计:

平均重试次数
2.3 → 0.4(↓83%)

Token 消耗
↓50-80%

任务成功率
↑30-50 个百分点

结论
约束显著提升效率

Skill 的本质

边界约束 + 路径约束

边界约束(Boundary Constraints)

定义「能做什么 / 不能做什么 / 必须做什么」

✓ 必须做:所有请求带 User-Agent
✗ 不能做:不允许绕过 robots.txt
○ 可选做:可以使用代理池

路径约束(Path Constraints)

定义「怎么做」--标准行为路径,减少试错

1. 读取 feeds.json
2. 用 feedparser 解析
3. 统一 JSON
4. 输出到指定路径

边界约束代码示例

# 数据抓取 Skill 的边界约束

## 必须做
- 所有请求必须带 User-Agent
- 每次抓取必须记录日志
- 输出必须是 JSON 格式

## 不能做
- 不允许绕过 robots.txt
- 不允许在 1 秒内发起超过 5 次请求
- 不允许存储用户隐私数据

## 可选做
- 可以使用代理池(如果配置了)
- 可以启用缓存(默认关闭)

路径约束代码示例

# RSS 抓取的路径约束

## 执行流程
1. 读取 feeds.json 获取 RSS 列表
2. 对每个 feed:
   a. 使用 feedparser 解析
   b. 提取最近 24h 内的条目
   c. 格式化为统一 JSON 结构
3. 按时间排序,去重
4. 输出到 output/digest-{date}.json
5. 生成 markdown 简报

## 异常处理
- 超时:重试 3 次,间隔 2s
- 解析失败:记录到 errors.log,继续下一个
- 全部失败:发送告警通知

Skill 价值 = 减少 Token 消耗 + 降低出错概率 + 节省调试时间

无 Skill：Agent 也许能完成任务，但要花更多 token 自己摸索路径，且每次路径可能不同

有 Skill：按既定路径执行，行为可预测、可复现、可调试

内容创作案例

# 写作 Skill 边界约束
- 必须先生成大纲再写正文
- 每段不超过 150 字
- 必须包含 2-3 个具体案例
- 不使用「首先、其次、最后」这类套话

# 写作 Skill 路径约束
1. 确认主题和受众
2. 生成 3 个备选标题
3. 选定标题后生成大纲
4. 逐段撰写,每段写完自检
5. 全文完成后整体审校

Memory 的本质:让 Agent 带着曾经的上下文工作

Memory 存储三类核心信息

身份:我是谁?我的角色?

偏好:用户/系统的偏好设置

资源位置:关键资源在哪里?

示例:「我是产品总监」「用户喜欢简洁输出」「配置文件在 /config」

Memory vs Skill

维度	Memory	Skill
本质	事实(Facts)	流程(Procedures)
加载时机	始终在上下文中	按需触发
更新频率	随时更新	相对稳定
记录	「工作内容」	「怎么工作」

# Memory 内容
- 我是小说连载执笔作者
- 项目:《星际迷途》
- 主角:李远(32岁)
- 世界观:2340年,殖民 7 个星系
- 用户偏好:硬科幻、对话简洁

# Skill 内容
1. 回顾上一章末尾 500 字
2. 确认本章目标
3. 生成场景大纲
4. 逐场景写作
5. 检查人物语言设定

总结

Memory 是「知道什么」，Skill 是「怎么做」

两者协同：Memory 提供上下文事实，Skill 提供执行路径

约束的分层架构

Skill(场景流程)--触发式加载

Constraints(通用约束)--每次会话加载(如果记忆体系包含该文件)

Memory(身份与事实)--自动注入

三层协同:Memory 提供事实,Constraints 提供边界,Skill 提供路径

分层的意义

1. Token 经济性:Skill 按需加载,避免 10 个 Skill 全部注入造成 20,000-50,000 token 浪费

2. 职责清晰:Memory 回答"知道什么",Constraints 回答"遵守什么",Skill 回答"怎么做"

3. 维护便利:改写作风格改 Skill,改通用行为改 Constraints,改项目背景改 Memory

用户发送消息

打开会话

注入 Memory

注入 Constraints

匹配 Skill 触发词

模型生成响应

始终发生

匹配成功
→ 加载 Skill

匹配失败
→ 跳过

分拆

Decomposition

单 Agent 为什么不够用？

当任务变长、角色变多、模型需求变复杂，单点能力会变成系统瓶颈。

瓶颈一：上下文窗口有限

• 128K tokens 看起来很大，但复杂任务很快耗尽
• 任务越复杂，需要保持的上下文越多
• 早期信息会被压缩或丢失

写 10 万字小说：第 1 章记得所有设定 → 第 5 章开始遗忘早期人物 → 第 20 章出现设定矛盾

研究经验：上下文超过 32K tokens 后，对早期信息召回明显下降

典型现象：「开头」和「结尾」更容易被记住，「中间」更容易丢失。

上下文长度 vs 召回准确率

瓶颈二：模式切换困难

• 单 Agent 需要在不同「角色」间切换
• 用户需要不断提示关键词来切换模式
• 切换不及时会导致混乱输出

用户：帮我写一段产品描述
Agent：[切换到文案模式] ...

用户：顺便检查一下代码里有没有 bug
Agent：[需要切换到开发模式，但可能还带着文案腔调]

角色混杂的本质：同一个上下文里同时塞进了多套身份约束。

瓶颈三：模型能力错配

复杂任务需要强模型；简单任务也用强模型，就是成本浪费。单 Agent 绑定单一模型，无法灵活调配。

任务类型	推荐模型	成本 / 1M tokens
复杂推理 / 规划/内容创作	Claude Opus	$15-75
代码编程	GPT-5.5	$3-15
格式整理 / 执行	deepseek-v4-pro	￥0.25-1.25

单 Agent 全程用 Opus：成本可能是分拆后的 5-10 倍。

分拆的维度

先看业务表层，再看技术深层

表层维度：按什么拆？

职能：按功能领域拆分 → 开发 Agent、写作 Agent、运营 Agent

流程：按工作阶段拆分 → 规划 Agent → 执行 Agent → 审核 Agent

深度：按决策层级拆分 → 统筹 Agent（决策）vs 执行 Agent（操作）

深层维度：技术上怎么拆？

技能集：不同 Agent 加载不同 Skill → 写作 Skill / 开发 Skill 隔离

模型：不同任务用不同模型 → 复杂任务 Opus/GPT，简单任务 DeepSeek

身份约束：不同角色带来不同决策倾向 → 产品全局优化，开发技术最优

分拆决策矩阵

低复杂度

高复杂度

高决策权重

专业执行Sonnet

核心决策Opus

低决策权重

批量执行Haiku

辅助分析Sonnet

实践案例

一个 8 Agent 的协作团队

团队架构图

主助手
协调中枢 / Opus

产品总监
产品规划 / Opus

主编
创作统筹 / GPT

开发
全栈开发 / GPT

作者
内容创作 / Sonnet

审校组
人物/场景/剧情 / Sonnet+Gemini+DeepSeek

运营
自媒体 / Opus

执行助手
纯执行 / DeepSeek

🧭

主助手

协调中枢

职能：全局调度，不陷入具体执行

模型：Opus；Memory：全局项目状态、各 Agent 状态

Skill：调度 Skill（分配任务、汇总结果）

典型任务：用户需求 → 拆解任务 → 分配给主编

📌

产品总监

产品规划与决策

职能：产品规划与决策

模型：Opus；Memory：路线图、用户反馈、竞品分析

Skill：需求分析 Skill、PRD 撰写 Skill

分拆理由：需要全局视角，不能被执行细节干扰

📝

主编

创作统筹

职能：选题、审稿、风格把控

模型：GPT；Memory：内容规范、发布记录、风格指南

Skill：选题 Skill、审稿 Skill

分拆理由：审稿要抽离，写作要沉浸

✍️

作者

内容创作

职能：正文写作、对话、场景描写

模型：Sonnet；Memory：作品设定、人物档案、世界观

Skill：写作 Skill、对话 Skill、场景描写 Skill

分拆理由：创作需要沉浸感，Skill 专注于技法

🔍

审校组

多维审核 / 大模型×3

人物审校：检查性格一致性、对话风格

场景审校：检查场景描写、时间线、空间逻辑

剧情审校：检查合理性、伏笔回收、节奏

分拆理由：三个视角各有侧重，单一 Agent 容易遗漏

📣

运营

自媒体运营

职能：标题、排版、发布策略

模型：Opus；Memory：平台账号、发布历史、粉丝画像

Skill：排版 Skill、标题优化 Skill、平台规则 Skill

分拆理由：平台规则、内容策略与创作本身是两套逻辑

💻

开发

全栈开发

职能：代码实现、调试、部署

模型：GPT；Memory：技术栈、代码库结构、API 文档

Skill：代码 Skill、调试 Skill、部署 Skill

分拆理由：代码 Skill 独立，可以选用代码专用模型

⚙️

执行助手

纯执行

职能：文件操作、格式转换、批量整理

模型：DeepSeek（最便宜）；Memory：无或极简

Skill：文件操作 Skill、格式转换 Skill

分拆理由：简单任务不需要强模型，极致成本控制

协作流程：写5篇 AI Agent 深度文章和社交媒体分享

Step 1
主助手
15s

Step 2
执行助手
30s

Step 3
产品总监
30s

Step 4
运营/主编
45s 并行

Step 5
运营/作者
2min 并行

Step 6
产品总监/主编
30s 并行

Step 7
执行助手
30s 并行

Step 8
主助手
15s

8 步协作：调度、验伪、定位、创作、审校、配图、汇报全链路并行提速。

协作流程 8 步

1. 主助手：需求理解、拆分任务、调度执行

2. 执行助手：查找资料和验伪

3. 产品总监：输出定位+核心观点

4. 主编和运营并行：输出文章和社媒内容的大纲/计划，并行完成5篇内容

5. 作者和运营并行：作者输出文章，运营输出社媒内容和配图方案，并行完成5篇内容

6. 主编和产品总监并行：审校内容

7. 执行助手：生成配图

8. 主助手：汇总并汇报用户

成本对比

单 Agent 全 Opus
$0.80

分拆 + 混合模型
$0.15

节省 81%

好处与代价

分拆不是免费的架构优化

四大好处

专注 Focus
Memory/Skill 更精准，不会被无关信息干扰，上下文利用率 ~30% → ~80%

并行 Parallelism
多个 Agent 同时工作，部分完成即可下一步，总耗时锐减

成本 Cost
简单任务用便宜模型，整体成本下降 81%

Skill 隔离
小说写作 Skill 和社交媒体写作 Skill 不互相污染

三大代价

协作成本
Agent 之间需要传递上下文；信息压缩可能丢失细节；需要交接协议。

知识同步
约束和画像要同步到所有 workspace；修改后需要版本一致性管理。

编排复杂度
调用关系、汇总时机、异常处理都需要专门设计。

上下文传递模板

# 上下文传递模板

## 任务背景
[1-2 句话]

## 输入
[结构化输入]

## 期望输出
[格式要求]

## 约束
[必须遵守的规则]

这是降低协作成本的标准化方案：把交接从「聊天」变成「协议」。

权衡公式

分拆收益 = 专注收益 + 并行收益 + 成本收益 + 隔离收益
分拆成本 = 协作开销 + 同步开销 + 编排开销

当分拆收益 > 分拆成本时，分拆有价值

任务可独立完成 → 适合分拆

任务需要频繁交互 → 谨慎分拆

复杂度差异大 → 适合分拆

任务量大可并行 → 适合分拆

任务环节单一步骤少 → 无需分拆

任务独立且延续性强 → 无需分拆

最后想说的三句话

约束不是束缚 而是让智能体行为可预测、可复现、可调试的工程基础。

分拆不是复杂化 而是把复杂系统拆成可并行、可优化、可降本的模块。

落地靠持续迭代 约束体系 + 分拆架构 + 评估反馈，才是真正的 Agent 工程化。

让模型从「会做」走向「稳定做好」。