agent（AI 代理）

一句话定义

Agent 是一个有角色、有任务边界、会自己做判断的 AI worker。
在这个 wiki 里，它通常落成一个 .md 文件: 你把“这个角色是谁、负责什么、不负责什么”写清楚，Claude 读到后就会按这个角色工作。

一句人话: agent 更像“岗位”，不是一次性 prompt。

为什么重要

当一类角色会反复出场，而且每次都需要一点判断，单靠聊天里临时交代很快就会乱。agent 的价值，就是把这个角色固定下来。

本仓库里已经有现成例子:

.claude/agents/ai-xueze.md 是 AI 学者，负责 raw -> wiki 的编译、lint 和 IA 守护。
PK 系统里的 Alfred、Tyrion、Jung、Sheep 是不同角色，不是同一个“万能 AI”的不同心情。

这也是为什么 agent 不是“给 AI 起个名字”那么简单。名字只是入口，真正重要的是边界: 谁该上场，谁不该上场。

技术机制

更宽泛的 AI 圈里，agent 常指“能自己用工具完成目标的 AI”。到了 Claude Code 这类 md-based 系统里，它通常表现为 .claude/agents/<name>.md 这样的角色文件，里面写清：

name / display_name: 这个角色叫什么
description: 什么任务该交给它
tools / model / permissionMode: 它能怎么干
正文协议: 它的工作目标、边界、交付物、禁区

Anthropic 官方对这类 worker 的核心强调有两点: 靠 description 决定何时委派，靠工具和权限约束能力边界。

所以 agent 的“技术本体”不是人格表演，而是三件事：

角色说明书
工具与权限边界
被调用时的稳定工作协议

如果这三件事没写清，agent 只是一个花名。

最小可跑通例子

最小版本可以先从一个只做评审的 agent 开始:

---
name: my-reviewer
description: Review changed code for readability and obvious risks. Use after edits are complete.
tools: Read, Grep, Glob
model: sonnet
---
只做评审，不改文件。
先列风险，再给建议。

放到 .claude/agents/my-reviewer.md 之后，你可以用自然语言让它上场，也可以在支持 agent delegation 的环境里显式派它：

Task(
    description="审代码",
    prompt="审查 src/auth.ts 的安全和可读性，只报高风险问题。",
    subagent_type="my-reviewer",
)

这里要注意: 被 Task(...) 派出去时，它就是 subagent 式运行；agent 是角色，subagent 是一种运行方式。

常见误解

把 agent 写成 skill。如果一段内容只是“固定步骤的做法”，没有角色判断，就不该伪装成 agent。
把 agent 和 subagent 当同义词。agent 讲的是角色；subagent 讲的是这个角色在独立 context 里被派出去执行。
一个 agent 囤太多责任。把“写作、审稿、发布”全塞进一个 agent，往往会把起草标准和评审标准搅在一起。更稳的做法是拆角色，再放进 workflow 里编排。
以为起个名字就算建好 agent。没有边界、没有禁区、没有交付物的 agent，最后还是会退化成“请你帮我做点什么”的通用聊天。

与其他术语的关系

[[subagent]]：agent 被独立派出去、在隔离 context 里干活时，就是 subagent 式运行。
[[skill]]：skill 是 agent 调用的技能包；agent 决定何时调用，skill 负责把某件事做稳。
[[workflow]]：workflow 决定先后顺序和协作方式；agent 是其中承担判断的参与者。
[[Harness]]：agent 不是凭空存在，它跑在一整套说明书、权限、工具和上下文规则组成的 harness 里。
[[CLAUDE.md]]：CLAUDE.md 提供项目级背景和共识；agent 在这个总说明书之上追加自己的角色协议。

陈彬视角

大多数人第一次搭系统，都先搞 Agent（因为有人格、好玩）。正确顺序其实是反过来: 先想清楚 workflow，再决定哪里需要 agent（有判断的地方），剩下的全是 skill。从 workflow 倒推 agent，不从 agent 发散出 workflow。

🎬 3 个场景（读者最可能用到的情境）

场景 1 · HR 设”面试官 agent”

HR 每周面试 5 个候选人。把”面试官”做成 agent：固定评估维度、追问策略、禁区（不问婚育/薪资倒推）、输出结构（结论 + 3 条证据 + 风险）。比每次重新贴 prompt 稳。

场景 2 · 写作者设”编辑 agent”

自由撰稿人写完初稿找 AI 审。做一个”编辑”agent：角色=带 10 年经验的非虚构编辑、只挑结构问题和事实漏洞、不改风格、不改句子。同一个编辑反复上场，标准才稳。

场景 3 · 散户设”风控 agent”

散户让 AI 做盘后分析，但怕它滑向”推荐”。做一个”风控”agent：只看仓位集中度/回撤风险/板块暴露，不给买卖建议，不预测行情。角色边界一写清，AI 就不越线。

⚖️ 和最像的邻居比

术语	本质区别	适用边界
agent	有角色判断的岗位	同一类任务反复出现、需要稳定视角
skill	一件事的做法	步骤稳定、不需要人格判断
subagent	agent 的一种运行方式（独立 context）	侧任务、只需要结论不需要中间过程
prompt	一次性指令	这轮就用、下次不复用

🚫 反例（不该这么用）

反例 1 · 一个 agent 做所有事

HR 建一个”万能人事 agent”，同时负责招聘、盘点、绩效、薪酬、合同审查。结果每次都得重新解释”这轮是哪个场景”，起草标准和评审标准全混在一起。正确做法：按场景拆 4-5 个独立 agent，每个只管一件事。

反例 2 · agent = 给 AI 起个名字

写一个叫”Kris”的 agent，里面只说”你是一个专业顾问”，没有边界、没有禁区、没有交付物。最后还是退化成通用聊天。正确做法：名字之外，必须写清”什么任务该给它 / 不该给它、输出什么、不做什么”。

❓ 常见误解

误解 1：“agent 越多越好” → 实际：每多一个 agent 就多一份维护成本和触发边界混乱，少而精 > 多而散，大多数系统 2-3 个 agent 就够。
误解 2：“agent = subagent” → 实际：agent 是角色定义，subagent 是”把 agent 放到独立 context 里跑”的运行方式，一个是名词一个是姿态。
误解 3：“先设计 agent 再想工作流” → 实际：正确顺序反过来——先想清楚 workflow，再决定哪个环节需要有判断的 agent。

🧬 历史坐标（最早谁提 · 本质 · 分型 · git）

最早谁提

“Agent” 作为认知单元的用法可追溯到 1986 年 Marvin Minsky 的《Society of Mind》——把心智看成由无数简单 agent 组成的社会。现代 LLM agent 从 2022 年 10 月 Shunyu Yao 等人的 ReAct 论文（arxiv:2210.03629，后发 ICLR 2023）开始工程化：让 LLM 交错产出 reasoning 和 action。

本质（一句话 · 20 字内）

有角色、有工具、会循环判断的 AI worker。

分型 / 演化（2-4 行主线）

1986 · Minsky《Society of Mind》奠定”心智 = agent 社会”的概念原型
2022-10 · ReAct 论文让 LLM 学会 reason + act 交错循环
2023-03 · AutoGPT 把 agent 带出实验室，点燃”LLM 自主完成目标”的社群想象
2025-07 · Anthropic 在 Claude Code 里用 .claude/agents/*.md 把 agent 角色化、文件化

代表 git / 文档

ysymyth/ReAct · Shunyu Yao · ReAct 论文官方实现
Significant-Gravitas/AutoGPT · Toran Bruce Richards · 首个破圈的 LLM autonomous agent
Building Effective Agents · Anthropic (2024-12) · Agent vs Workflow 的权威分类

AI·系统·创造·人将如何自处

探索