AI Agent / Developer workflow开发者分享

从工具到队友

AI Agent：
开发者的“硅基队友”

从 AI 工具到 AI 队友：企业 IT 的 AI Coding 实战

真实任务工具调用人审边界

AI
×
IT

CONTENT MAP44 PAGES / DETAILED INDEX

01 / 基础与方法

关于我P3

从答案到任务P4

先看任务P5

Agent loopP6

第一次使用P7

马上能用P8

可靠性P9

维护老系统P10

02 / Skill 与团队经验

把经验变成 SkillP11

Skill Best PractiseP12

Skill Best Practise / QualityP13

03 / Spec、Loop 与 Token

Spec-Driven DevelopmentP14

最小 Feature SpecP15

大型 Spec 的拆分P16

用 /goal 执行 SpecP17

Agent loop：新功能开发P18

Agent loop：一次迭代如何推进P19

Token 使用优化：预算P20

Token 使用优化：Codex 与 Claude CodeP21

Token 使用优化：自建 AgentP22

04 / LLM Observability

三层运行时P23

AutoGen 接入观测层P24

从 Trace 到 GuardrailP25

05 / 运行边界与开发方式

边界与人审P26

Prompt Engineering 到 Graph EngineeringP27

工作方式变化P28

三个产品开发反馈循环P29

从工具到工作流P30

LLM 幻觉P31

06 / 知识、模型与 Multi-Agent

RAG：把知识接入 AgentP32

RAG：蒸馏层P33

LLM 选择P34

选择正确的 Agent 模式P35

Agent 设计模式框架P36

国内开发者的工具选择P37

高阶 Agent 模式：循环型P38

高阶 Agent 模式：编排型P39

代码与判断P40

多个 Agent 如何通信P41

AutoGen：消息协作P42

LangChain / LangGraph：状态协作P43

结束P44

本次 AI Agent 开发者团队分享分为两场：基础篇与进阶篇。

03 / 44About me

关于我

从真实工作出发，把 AI 变成队友。

Wade 邓维

MaybeAI 联创 & 技术负责人

帮助过多家年营收几千万到亿的跨境电商企业落地 AI。

X: @no7wadeWechat: @no7wade

RoadToAGI 频道二维码 — RoadToAGI · Scan QR code to view my channel

04 / 44重新认识 AI

认知变化

聊天 AI 是好的开始，
但不应该是终点。

过去：问一个问题

我有一个问题
↓
AI 给我一个答案

→

现在：完成一件事

我有一个目标
↓
AI 读、改、跑、验证

05 / 44工具选择

不要先选工具

先看任务，再选择
最合适的 AI 方式。

直接 Call LLM分类、摘要、翻译、信息抽取

Python / Shell文件、数据、日志、批处理

Workflow / RPA固定流程、跨系统搬运

Coding Agent读代码、改 Bug、补测试

Agent复杂目标、多步骤动态决策

“哪个 AI 工具最好？”换成：这个任务是什么？什么方式最适合让 AI 完成它？

选择够用的模型。
推理强不等于适合高频小任务。代码、速度、上下文、成本和工具调用能力，都要放回真实工作里比较。

06 / 44基本原理

Agent 为什么能干活

它不是更会聊天，
而是多了一个行动闭环。

目标

你说清楚要达到什么结果。

规划

AI 拆解任务，决定先做什么。

工具

读文件、搜索、运行命令、跑测试。

证据

看到真实结果，而不是凭空猜。

下一步

根据结果继续行动，直到验收。

传统聊天：回答后结束。
Agent：做一步、看结果、再决定下一步。

07 / 44第一次真正使用 Agent

从一个真实任务开始

给订单模块增加一个导出功能。

先理解项目，找到订单导出相关代码。告诉我准备怎么改，先不要修改。

方案可以，开始修改。只修改订单模块，不改变数据库结构。

修改完成后运行测试，告诉我结果。失败就分析原因并修复。

// AI 的工作轨迹 read files → search code ↓ edit → run tests ↓ inspect evidence → fix ↓ report result

08 / 44日常 IT 工作

今天就能开始

把 AI 放进你已经在做的工作里。

查 Bug先分析原因，再提出修改。

看日志找异常、归类、形成假设。

查 SQL参数、数据、执行结果一起看。

改配置限定文件和允许的变化。

看老代码解释调用链，不急着重构。

写脚本让 LLM 先生成可运行版本。

补文档把项目上下文写下来。

补测试让结果有验收标准。

三句提示词：先理解。给边界。让它验证。

09 / 44让 AI 写得更可靠

不是一次写对

AI 写得快，验证机制决定它能不能交付。

需求明确结果

→

AI 修改产生变化

→

运行测试拿到证据

→

失败反馈暴露问题

→

修复再测直到验收

允许 AI 犯错，
不允许没有证据。

项目上下文也要沉淀

README：项目是什么、怎么运行。
AGENTS.md：哪些目录能改、测试怎么跑、哪些操作必须确认。

10 / 44维护型开发者

第二双眼睛

Debug 不是让 AI 猜 Bug，
而是让它沿证据链定位。

01 / 输入

用户现象、发生时间、请求参数、环境差异。

02 / 日志

错误堆栈、上下游请求、异常频率、关联 ID。

03 / 假设

可能原因、涉及模块、需要验证的关键点。

04 / 验证

复现、查询数据、运行测试、确认修复没有副作用。

找证据 → 提出假设 → 验证假设。一次解决问题是干活，方法沉淀下来才是队友。

11 / 44把经验变成 Skill

从个人能力到团队能力

Skill 不是 Prompt 收藏夹，
而是可执行、可验收、可复用的方法。

场景

什么时候使用？

输入

需要什么材料？

流程

按什么步骤执行？

停止条件

什么情况不能继续？

输出

最后交付什么？

验收

怎么判断成功？

12 / 44Skill Best Practise

触发之前，模型只看到元数据

Skill Best Practise：先被正确发现，
再被正确执行。

保持简洁。删掉模型已经知道的常识；每一段都要值得占用上下文。
匹配自由度。启发式任务给高自由度；有固定模式用模板；脆弱操作给精确步骤。
做好元数据。启动时预加载 name + description；它们决定 Skill 是否会被发现和触发。
让内容可维护。引用走一层、文件名描述性强；旧方法单独归档，避免主流程过时。

使用渐进式披露。主 SKILL.md 保持精简，完整细节放到按需加载的参考文件。
统一术语与示例。同一个概念只用一个称呼，示例要具体；同时给出一个默认路径，不要罗列过多选项。

# discoverability metadata name: analyzing-sales description: Analyzes sales data and builds reports. Use when users ask for revenue, pipeline, or performance analysis.

读取顺序：
启动时：预加载 name + description
触发后：读取 SKILL.md
按需：读取 reference/ 等文件

写作原则：description 写能力 + 触发场景；步骤、边界和验收放进 SKILL.md。

13 / 44Skill Best Practise

把质量变成可观察的反馈

真正的质量来自测试、验证与持续迭代。

复杂任务写工作流。用清晰、连续的步骤和 checklist，降低漏步骤的概率。
建立反馈闭环。执行验证 → 修复问题 → 再次验证，直到验收通过。
给关键操作设停止条件。高风险、破坏性或不可逆动作，先生成计划再执行。
产出可验证的中间结果。批量修改、表单填充等任务先生成计划文件，再校验、执行、复核。

脚本要解决问题。显式处理错误，解释关键参数，列出依赖；不要把难题丢回给模型。
确定性操作优先用工具。能直接运行的 utility script，比每次临时生成代码更可靠。
先做评估再写长文档。至少准备三个场景，先建立无 Skill 基线，再测试不同模型与真实任务。
观察真实使用行为。关注漏读引用、反复探索、被忽略的内容，并吸收团队反馈持续改版。

不要凭感觉写说明书，用真实使用行为观察 → 修正 → 再测试。

14 / 44Spec-Driven Development

把意图写成可验证的契约

Spec 不是实现计划，
而是可验收的任务契约。

Spec 写什么 / WHAT

为什么做：背景、目标、用户价值。
改哪里：范围、边界、明确不做什么。
要做到什么：行为、输入输出、错误和不变量。
怎么判断完成：场景、验收标准和验证方式。

Plan 写什么 / HOW

选择哪些模块、文件和技术方案。
怎样拆任务、安排顺序和分配责任。
怎样落地实现、迁移、回滚和发布。
这些决定应基于仓库现状，而不是写死在 Spec 里。

写下不能靠猜的决定，把可以从仓库发现的决定留给 Agent。

15 / 44Spec-Driven Development

足够严格，也足够容易维护

一份够用的 Feature Spec，
先把“什么必须为真”写清楚。

# specs/account-deletion.md # Feature: Account deletion ## Intent 删除账号后不再拥有有效会话。 ## Scope - In: deletion and active sessions - Out: registration and billing history ## Requirement - 删除后，所有 active sessions 立即失效。 ## Scenario Given active sessions → When deleted → Then reject ## Acceptance - [ ] Existing sessions cannot authenticate - [ ] Registration flow is unchanged

WHAT：所有 active sessions 必须立即失效。

HOW：是否新增 revokeSessions()、放在哪个 Service、使用什么存储，由 Agent 先检查仓库再提出 Plan。

关系：Spec → Acceptance Criteria → Tests。测试是可执行的验证，不是 Spec 本身。

16 / 44Spec-Driven Development

大项目不要写一份巨型 SPEC

把复杂目标拆成阶段、局部文件和可验证结果。

01Intent为什么做

02Specify写清契约

03Clarify解决歧义

04Plan决定如何做

05Tasks拆成任务

06Implement分阶段实现

07Validate对照契约验收

project/ ├── AGENTS.md ├── specs/ │ ├── product.md │ ├── architecture.md │ ├── auth/ │ │ └── auth.md │ └── billing/ │ ├── billing.md │ └── invoice.md └── src/ ├── auth/ └── billing/

AGENTS.md 放项目级规则；product.md 与 architecture.md 放稳定的全局上下文。
领域 Spec 放在 specs/auth/、specs/billing/，靠近对应的业务边界。
Agent 一次只加载当前阶段、当前领域需要的文件，避免巨型上下文。
大型重构先切边界，再切迁移批次；不要一次改完整个系统。

17 / 44Spec-Driven Development

让 Agent 按阶段推进，而不是一次性冲刺

用 /goal 把 Spec 变成有状态的执行循环。

# 示例：把目标、范围和验证一起交给 /goal /goal 读取 specs/checkout/ 按 Phase 1 → Phase 3 执行每个 Phase：Plan → Implement → Validate 完成后汇报证据和剩余风险遇到范围或契约不清：先暂停提问

指定入口：给出 Spec 文件或目录，不让 Agent 自己猜上下文。
指定阶段：一次推进一个 Phase，完成验证后再继续。
指定状态：每阶段记录完成项、证据、风险和下一步。
指定停止条件：边界、权限、数据契约不清时先停，不要擅自扩大范围。

/goal 不是替代 Spec 的魔法命令；它的价值是让目标、阶段、验证和停止条件持续可见。

18 / 44Agent loop / 新功能开发

把一次交付变成可观察的迭代

新功能不是“一次生成”，
而是目标驱动的行动闭环。

01 / GOAL明确目标读取 Spec，确认范围、验收和停止条件。

02 / EXPLORE探索仓库搜索符号、依赖和现有测试，只取相关上下文。

03 / PLAN提出计划拆成小步骤，先让人确认高风险决定。

04 / IMPLEMENT执行修改按阶段编辑代码，每次变更保持可回退。

05 / VERIFY验证证据运行测试、检查 diff，对照 Acceptance Criteria。

06 / NEXT完成或继续满足条件就停止；失败则带着证据进入下一轮。

核心：每一轮都回答“当前状态是什么、下一步为什么做、什么证据可以停止”。

19 / 44Agent loop / 一次迭代

让每一步都能复盘

以“订单导出”为例：
Agent 通过证据 → 决策 → 验证推进。

# iteration 03: implement export endpoint goal: add order export state: API contract clarified read: orders/service.ts, orders.test.ts plan: add CSV serializer + endpoint test edit: 2 files changed run: npm test -- orders evidence: 18 passed, diff reviewed decision: continue → add permission case

进入：Spec 已明确输入、输出、权限和验收标准。
行动：先搜索相关符号和测试，不读取整个仓库。
反馈：工具结果只保留失败、差异和下一步需要的证据。
停止：功能验收通过，或遇到契约、权限、数据风险时暂停。

INPUT目标与上下文Spec + 当前状态

ACTION工具与修改一次小步

FEEDBACK结果与证据测试 / diff / 日志

DECISION继续或停止遵守边界

20 / 44Token Engineering

先看总账，再优化句子

Token 成本不只来自 Prompt，
更来自重复上下文 × Agent 循环次数。

Input tokens

系统指令、历史对话、工具 Schema、代码、RAG 结果。

重复发送 = 隐性成本

Output tokens

回答、推理、工具参数和失败后的重试内容。

max_output_tokens

Number of calls

一次分类、提取、总结、格式化，是否真的需要四次调用？

少循环，少重试

Total cost ≈ input tokens × input price + output tokens × output price × number of calls

优先级：Prompt caching → context compaction → tool filtering → model routing → loop / call reduction。

21 / 44Token Engineering / Coding Agent

你控制不了全部循环，就先控制进入上下文的内容

Codex / Claude Code：先压缩工具输出。

RTK 的位置

Agent runs shell command
　　　 ↓ hook rewrites
RTK executes the real CLI
　　　 ↓ filter / summarize / dedupe
compact output
　　　 ↓
LLM context

它不改变模型，只改变 Shell 输出进入上下文的形状：单个 Rust binary、100+ 命令、低开销。

为什么会变短

Smart filtering：去掉注释、空白、模板和进度噪声。

Grouping：按文件、目录、规则或错误类型聚合。

Truncation：保留关键上下文，截掉重复长行。

Deduplication：重复日志折叠为一条并附出现次数；测试通常只保留失败项。

边界要说清：RTK 官方称最多可减少 90% 的 Bash 输出，但这不等于账单减少 90%。它只控制输入 Token 的一个来源；rtk gain 用 bytes / 4 估算 Token，百分比有意义，绝对值不是供应商账单。官方仓库

22 / 44Token Engineering / Own Agent

自建 Agent 可以控制整个循环

把 RTK 的思想升级为Token-aware Tool Middleware。

01 / TOOL OUTPUT压缩结果truncate、summarize、deduplicate，只返回对下一步有用的信息。

02 / CONTEXT按需取证RAG top 3–5、摘要旧历史、缓存稳定前缀和结果。

03 / SCHEMA筛选工具按任务暴露工具组，减少无关 Schema 和错误调用。

04 / MODEL任务路由简单分类用小模型，复杂规划和编码用强模型。

05 / LOOP控制循环并行调用、限制重试、设置 max turns 和明确终止条件。

Tool → raw result → token optimizer → diff / cache / structured extraction → agent context

两种场景的差别：Codex / Claude Code 主要让工具返回更少；自建 Agent 还可以决定“何时取、取什么、调用几次、何时停止”。

23 / 44LLM Observability

观察 Agent，才能解释它为什么这样行动

Runtime、Instrumentation、Evaluation
是三层不同的职责。

Problem / Layer	Claude Code	Codex	AutoGen	LangChain / LangGraph
Persistent instructions	CLAUDE.md	AGENTS.md	System messages / agent config	Prompts / system messages
Reusable workflows	Skills	Skills / instructions	Agent / workflow / component	Tools + prompts / LangGraph nodes
Agent routing	Skill descriptions	Instructions + scope	Router agent / workflow logic	Conditional edges / router
Tracing	OpenTelemetry + telemetry	Less publicly exposed	Events / callbacks / OTel	LangSmith Tracing
Loop control	maxTurns + runtime limits	Runtime limits	max turns + termination	recursion limit + state control
Evaluation	External eval tooling	External eval tooling	Custom evaluator	LangSmith Evaluations
Guardrails	Hooks + permissions + sandbox	Sandbox + approvals	Tool guards / middleware	Middleware / guard nodes
Cost / tokens	Telemetry / usage	Usage reporting	Instrument LLM calls	LangSmith token tracking

关键分工：LangGraph 控制流程，LangSmith 观察与评估；AutoGen 也可以把事件接入 LangSmith / OpenTelemetry。

24 / 44LLM Observability / AutoGen

Runtime 与 AgentOps 可以解耦

AutoGen 负责运行，
LangSmith / OpenTelemetry 负责看清运行。

# AutoGen runtime Your Application ↓ AutoGen Runtime │ ┌────┼────┐ ▼ ▼ ▼ Agent Tool Workflow │ events ▼ OpenTelemetry ──→ LangSmith

Agent / Tool：记录 message、decision、参数、结果、错误和耗时。
LLM：记录 model、input/output tokens、latency 和 cost。
Trace tree：把一次 run 里的 LLM、Tool、Hook、Subagent 关联起来。

Agent Runtime ≠ Observability ≠ Evaluation
AutoGen / LangGraph / Custom → OpenTelemetry → LangSmith / Phoenix → Trace → Eval

不要重造 AgentOps：自建系统应优先定义事件和 trace contract，再选择 LangSmith、Phoenix 或其他后端。

25 / 44LLM Observability / Quality Loop

追踪不是终点，生产质量需要闭环

Trace 发现模式，Evaluation 证明问题，
Guardrail 防止复发。

Skill Selection Accuracy选中的 Skill / Agent 是否真的适合任务？

Skill Repetition Rate同一能力是否被无意义地重复调用？

Skill ChurnA → B → A → B 是否代表路由不稳定？

Agent Loop Length完成一个目标用了多少轮、多少工具调用？

Unnecessary Calls哪些工具/技能调用没有改变下一步决策？

Successful Termination是否按验收标准完成，而不是因达到上限退出？

Trace: revenue-analysis → data-cleansing → revenue-analysis → data-cleansing
Evaluation: unnecessary repetition
Guardrail: max_same_skill_calls = 2
Skill redesign: add explicit exit condition
Regression: task X ≤ 5 skill invocations

生产闭环
Tracing → Evaluation → Guardrail → Skill redesign → Regression test

不要只记录“发生了什么”，还要记录 Agent “为什么选、为什么继续、为什么停止”。

26 / 44自主执行的边界

企业真正要决定的事

不是“AI 能不能做”，
而是“我们允许它做到哪一步”。

开发环境

更自由

读代码、改代码、运行测试。允许快速试错。

测试环境

可执行

指定目录可写，指定命令可跑，关键结果需确认。

生产环境

只读优先

读日志、查数据、给建议。危险操作与最终责任由人承担。

全部人工人做、AI 看

AI 建议人决定

AI 执行人确认

关键步骤人审边界内自动化

全自动仅适合低风险场景

27 / 44从 Prompt Engineering 到 Graph Engineering

下一阶段不是学更多名词

LLM 越来越能理解、行动、协同，
我们的工作也就从“写提示词”上移到“设计系统”。

01 / Prompt Engineering

告诉它怎么做

把一句话写得更清楚。

LLM：遵循指令

02 / Context Engineering

让它知道在哪做

项目、规则、资料进入上下文。

LLM：利用上下文

03 / Spec Engineering

定义什么算完成

输入、输出、边界、验收可观察。

LLM：拆解任务

04 / Goal + Loop Engineering

给目标，允许迭代

做一步、看结果、再决定下一步。

LLM：规划与调用工具

05 / Harness Engineering

给它运行的护栏

测试、权限、工具和反馈被固定下来。

LLM：在边界内执行

06 / Graph Engineering

设计任务图

让多个步骤、Agent 和人协同。

LLM：协调复杂系统

每一次上移，都是因为上一层开始变成瓶颈：提示词不够，就补上下文；上下文不够，就补规格和反馈。

28 / 44能力变化，工作重点也变化

从写 Prompt 到设计运行环境

LLM 能力上升以后，
开发者不再只负责“产出文本”。

阶段

LLM 能力变化

我们的工作重点 / 工作方式

Prompt Engineering

从听懂一句指令，到稳定遵循格式和语气。

练习表达任务，检查输出，反复改写提示词。

Context Engineering

能把项目资料、规则和历史信息放进判断。

整理上下文，维护 README、AGENTS.md、知识边界。

Spec Engineering

能把自然语言目标拆成步骤、约束和结果。

先定义输入、输出、异常和验收，再让 AI 执行。

Goal / Loop Engineering

能规划、调用工具、观察结果、修正路径。

从“写一次”改成管理反馈循环，盯证据和状态。

Harness Engineering

能在测试、权限和工具约束中完成任务。

设计运行环境：测试、权限、工具、回滚和人审。

Graph Engineering

能协调多个 Agent、工作流和依赖关系。

设计任务图、节点责任、交接、Eval 和系统级反馈。

LLM 的变化：从回答问题，到在上下文和约束里完成目标。

人的变化：从亲自做每一步，到设计目标、边界、反馈和协作图。

29 / 44三个产品开发反馈循环

三个产品开发反馈循环：Agentic Coding Loop、Developer Feedback Loop、External Feedback Loop

循环越外层，反馈越慢，但越接近真实产品：分钟级执行，小时级校准，天级验证。

30 / 44从工具到工作流

下一次工作就开始

不要先学 Agent，
先让 AI 帮你完成一个真实任务。

挑任务

高频、重复、结果可判断。

给边界

限定目录、命令、环境。

跑验证

测试、日志、人工验收。

写成 Skill

把方法变成可复用流程。

持续改进

用真实反馈迭代。

31 / 44LLM 幻觉：原因与解决

生成合理，不等于事实正确

LLM 会“编造”，不是因为它想撒谎。
而是生成 ≠ 验证。

为什么会发生

概率生成

模型优先生成“像答案”的文本，不会自动为事实背书。

上下文缺失

没有企业规则、真实数据或最新资料，只能依赖已有模式。

边界模糊

问题太大、输入不完整、验收不清，模型容易补齐不存在的信息。

怎么解决

给它依据

接入文档、数据库、工具和可追溯来源，不让它凭空回答。

让它可验收

要求引用、结构化输出、测试、规则检查和失败证据。

保留人审

事实、数字、权限、法律、财务和业务规则不直接外包。

高风险判断不能只问“像不像答案”，要问：依据是什么？如何验证？谁负责？

32 / 44RAG：把知识接入 Agent

让回答有依据，让行动有上下文

RAG 的演进：从一次检索，到 Agent 按需取证并行动。

RAG 三层架构：Naive RAG、Retrieval Layer、Agentic Layer

企业落地的关键：数据新鲜度、来源可追溯、权限和验收。参考 RAG 架构图

33 / 44RAG：蒸馏层

RAG 的质量，在检索之前就决定了

先修复知识单元，
再去调向量检索。

蒸馏层在向量化前，把文档变成更小、更干净、带治理信息的问答知识单元。

Chunk 是被忽略的前提。按 token 切出的文本没有想法边界、版本上下文或权限状态，检索容易返回不完整或互相冲突的证据。
用问答包替代文本窗口。一条经过验证的事实，加上类型化治理字段，让索引单元匹配用户真实的提问方式。
在向量化前做蒸馏。在所给基准中，语义去重最多将语料缩小 40 倍，查询 Token 减少 3 倍，检索距离改善约 2.3 倍。
让治理字段随数据走。版本、密级、隐私和来源元数据跟随每个知识块，而不是依赖脆弱的编排层逻辑。
七个阶段让故障可定位。范围定义、摄取、抽取、去重、自动打标、专家校验，最后导出到向量库。

实践规则：先在上游清理并结构化知识单元，再让检索、重排和 Embedding 专注于匹配。

34 / 44LLM 选择

模型不是越强越好

选模型，不是找“最强”，
而是找任务的最佳性价比。

Codex Radar：横轴是相对综合成本，纵轴是 IQ。图表适合看相对位置，不是单一绝对榜单。

高难任务

复杂 Debug、架构、Spec：优先看推理和代码理解能力。

高频任务

日志整理、摘要、简单修改：速度和成本更重要。

真实基准

用自己的任务比较代码、上下文、工具调用、速度和成本。

35 / 44Agentic Design Patterns / 决策树

模式选择，从任务开始

根据任务属性选择模式。
不要先从架构开始。

根据任务属性选择 Agent 设计模式的决策树。

1. 先看路径是否已知。如果流程确定且可预测，使用顺序工作流；只在需要理解或生成的地方调用模型。
2. 按需增加能力。开放式任务需要工具和外部信息，接入 API、数据库、文档和系统操作。
3. 区分规划与探索。阶段和依赖关系清晰时使用 Planning；结构在执行中逐渐形成时使用 ReAct。
4. 有意识地为质量付费。质量标准明确、错误成本足够高时，再增加 Reflection 和额外延迟。
5. 只为真实瓶颈扩展。只有专业化或规模问题确实存在时才使用 Multi-Agent，否则单 Agent 通常已经足够。

模式是起点。随着反馈、约束和失败信号积累，持续重新评估。

36 / 44Agentic Design Patterns / 框架

模式 = 能力与执行形态的组合

用两种视角定位模式：
Agent 做什么，以及工作如何流动。

Agent 设计模式框架：认知功能 × 执行拓扑。

纵向看认知功能。感知、记忆、推理、行动、反思、协作和治理，描述 Agent 正在完成什么工作。
横向看执行拓扑。链式、路由、并行、循环、层级和编排，描述工作与控制如何流动。
模式是可组合的积木。例如 RAG Pipeline、Tool Dispatch、Plan-and-Execute、Fan-Out / Gather 和 Hierarchical Delegation。
跨切面能力保证可运营。Observability、Evaluation & Validation、Security & Identity 贯穿整个矩阵。
设计含义：先定位所需能力和拓扑，再组合解决任务所需的最小模式集合。

决策树负责选择起点，矩阵负责展示如何组合。

37 / 44国内开发者的工具选择

环境不同，工作方式可以保持一致

不能稳定使用某个海外工具，
不等于不能开始 AI Coding。

Artificial Analysis Intelligence Index：模型能力与成本分布

Artificial Analysis Intelligence Index：用能力与成本的分布建立选择基线。

Coding Agent
Trae、WorkBuddy、Qwen Code、智谱等国内可落地选择。

模型 / API
按代码、推理、上下文、速度和成本选择“够用”的模型。

模型路由
用 CC Switch 或类似路由，把多个模型接入同一个工作环境。

工作重点
不要绑定一个品牌；让任务、权限、测试和验收保持稳定。

模型排行榜是输入，不是决策。先用真实任务跑 Benchmark，再决定工具组合。

38 / 44高阶 Agent 模式 / 循环型

高阶内容 01

先看 Agent 如何思考、行动、修正。

ReAct

规划：低 / 隐式　自适应：★★★★★

[Task]
  |
[Thought] -> [Action]
                 |
           [Observation]
                 |
              [Thought]
                 |
              [Action]

开放式任务、搜索、工具调用、故障排查。

Reflection / Self-Critique

规划：中　自适应：★★★★★

[Draft / Run]
      |
  [Evaluate]
    /     \
[Pass]  [Improve]
  |        |
[Done] <---+

执行后自己评估并改进，适合 Coding、写作、数据分析。

Tree of Thoughts

规划：高　自适应：★★★★☆

[Problem]
    |
+---+---+
|   |   |
[A] [B] [C]
 \   |   /
  [Evaluate]
      |
 [Best path]

同时探索多个方案，再评估并选择最佳路径。

循环型 Agent 的差异：反馈发生在一次任务内部。29

39 / 44高阶 Agent 模式 / 编排型

高阶内容 02

再看 Agent 如何拆任务、分角色、组织状态。

Plan-and-Execute

规划：高　自适应：★★★★☆

[Goal]
  |
[Plan]
  |
+---+---+
|   |   |
[S1][S2][S3]
 \   |   /
 [Replan?]

目标明确的多步骤任务，先规划，再执行，必要时重规划。

Graph / Workflow Agent

规划：显式　自适应：★★★☆☆

[State]
   |
[Node A] --> [Node B] --yes--> [Node C]
   |              |
   +----- no -----+
                  |
              [Human]

企业流程、确定性强的业务规则，状态和分支都可追踪。

Multi-Agent

规划：分布式　自适应：★★★★☆

            [Manager]
           /    |    \
        [Agent A][Agent B][Agent C]
           \    |    /
          [Shared result]
                |
             [Deliver]

不同专业能力并行协作，适合角色分工和复杂交付。

编排型 Agent 的差异：把一次回答变成可管理的任务系统。30

40 / 44AI 时代的开发者能力

AI 越强，人的稀缺价值越集中在判断

代码会越来越便宜，
但判断会越来越贵。

01 / 需求建模（链接物理世界）

把现实目标变成可执行契约

把真实业务、用户场景、范围和验收条件讲清楚。输入越含糊，Agent 越容易快速放大错误方向。

02 / 架构裁量

用约束缩小可选空间

把模块边界、数据不变量和架构原则写成 Agent 能执行的规则，把长期经验沉淀为可复用约束。

03 / 质量担责（链接物理世界）

用证据守住真实后果

让测试、评审、发布门禁、线上观测和用户反馈形成证据链。代码可以由 AI 生成，质量风险仍需要人来承担。

投入要按风险分配：标准化、低风险的小团队项目可以少做架构仪式；复杂系统、关键数据和长期演进仍需要明确约束。AI 会接管越来越多的架构实现，但不会自动替你承担后果。

41 / 44Multi-Agent / Distributed Systems

不要把多个 Agent 只设计成群聊

多个 Agent 如何通信？
先把它当成分布式系统。

# task and message flow User Goal │ ▼ [Router / Manager] ┌─┼──────────┐ ▼ ▼ ▼ Planner Researcher Coder └────┬─────┘ ▼ [State / Event Log] ▼ [Reviewer] pass / retry / stop

消息契约：task_id、sender、recipient、type、payload、evidence。
状态所有权：一个 Agent 负责写入，其他 Agent 提交建议或只读。
失败边界：超时、重试、重复消息、背压和权限都要显式处理。
终止与观测：定义 DONE 条件，并记录消息、决策、工具、Token。

通信模式	结构	适合场景	主要风险
Point-to-Point	Agent A → Agent B	明确的任务交接	强耦合、单点依赖
Broadcast / Group Chat	一条消息 → 多个 Agent	共享上下文、多人评审	上下文膨胀、重复响应
Broker / Event Bus	Agent → Broker → Agent	事件驱动、异步协作	消息顺序、重复消费
Shared State	Agent ↔ State Store	长流程、可恢复任务	状态竞争、权限混乱

判断标准：先决定谁能看到消息、谁能修改状态、谁有权继续，再决定通信拓扑。

42 / 44Multi-Agent / AutoGen

Runtime 把参与者、路由和终止条件放在一起管理

AutoGen：把 Agent 协作变成可管理的消息系统。

# AutoGen: message-oriented team Task │ ▼ [Team / Manager] ┌──┼─────────┐ ▼ ▼ ▼ Planner Researcher Reviewer └──┬────┘ ▼ Runtime topics + tools ▼ termination condition

参与者：用 AssistantAgent 表示不同角色，按职责接收任务或输出证据。
消息路由：Team / Manager 将消息发布给参与者；参与者共享必要上下文，但不共享所有内部状态。
工具边界：通过 FunctionTool、AgentTool 或 MCP 暴露能力，工具仍需权限、超时和幂等控制。
停止条件：TerminationCondition、最大轮次和人工介入共同防止无限协作。

message = { task_id, sender, recipient, type, payload, evidence, created_at }
trace = run → participant message → tool call → result → next decision → termination

分布式映射：Agent 是服务角色，Team / Manager 是路由层，Runtime topic 是消息地址，termination 是系统停止条件。 AutoGen 官方仓库

AutoGen 当前处于 maintenance mode；这里把它作为多 Agent Runtime 的通信示例，新项目也应评估 Microsoft Agent Framework。

43 / 44Multi-Agent / LangChain

把消息交接显式化为状态变化与条件边

LangChain / LangGraph：
用状态图表达 Agent 如何继续、分支和结束。

# LangGraph: state-oriented workflow START │ ▼ [Planner] ── conditional ──┐ ├──→ [Researcher] ────────┤ └──→ [Coder] ─────────────┘ │ ▼ [Reviewer] / \ pass fail │ │ END ───→ Coder

State：共享 goal、evidence、draft、review、attempts，每次更新都可追踪。
Node：每个节点可以是 Agent、工具或确定性函数，输入状态，返回局部更新。
Conditional edge：根据状态选择下一节点，把路由规则从隐式对话变成显式控制流。
观测与评估：@tool 负责能力，LangSmith 负责 trace、数据集和评估，运行时与观测层解耦。

设计层	AutoGen	LangChain / LangGraph	分布式系统考虑
Agent	AssistantAgent	Agent / graph node	服务角色与职责边界
Communication	Team publish / manager route	State update / graph edge	广播、直连还是事件
State + termination	Runtime / team state + condition	StateGraph state + END	单一写入者、预算、恢复
Tools + observability	FunctionTool / events / callbacks	@tool / LangSmith tracing	权限、trace、metrics、eval

选择：AutoGen 更容易展示“消息如何流动”；LangGraph 更容易把“状态如何变化、下一步为何发生”写成显式图。两者都需要消息契约、状态所有权、失败处理和终止条件。

44 / 44带走三句话

结尾

AI 不一定替代开发者，
但会重新定义开发者每天做什么。

先让 AI 帮你完成一个真实任务。
再把经验、SOP 和上下文教给它。
在正确的边界里，让它尽可能自动化。

01 / 真实任务

优先使用 Coding Agent，先让 AI 帮你完成一件真实工作。

02 / 上下文

把项目、经验、SOP 和工作方式教给 AI。

03 / 边界

明确权限、测试、验收和哪些内容不能直接外包。

04 / 自动化

在正确的边界里，让 AI 尽可能自动化并持续反馈。

目标上下文边界验证

AI Agent：开发者的“硅基队友”