Aklman · Library

— 01 / 第一章

引子 · 什么是 Agent，什么不是.

Agent 不是更大的 prompt，不是更长的对话。它是一个循环 —— 感知、决策、行动、观察，然后再来。

9 分钟 · 初稿 2026.05 · v3 2026.07

MD海报
你大概已经写过一个套壳聊天框，调过几次 API，也许还试过 AutoGPT —— 看着它自己跟自己聊了二十轮、烧了五美元、绕回原地。现在「agent」是 AI 圈最被滥用的词：每个框架都说自己在做 agent，每条推都在发 agent。这一章不教你建，先帮你把线画清：agent 到底是什么，以及更有用的那一半 —— 它不是什么。 这本书是一个从零动手的项目：从一个只会聊天的 LLM 出发，一章加一种能力，直到它能在真实环境里干活。但动手之前，得先有判断 —— 不然你会把一个本该是一行函数的活，建成一个会绕圈的 agent。 动手有动手的对象。这本书从头到尾建同一个东西：一个研究 / 分析助手 —— 你给它一个问题，它去搜、去抓网页、在沙箱里跑分析代码、记住中间结论，最后回一份带引用的报告。每一章给它加一种能力，到最后你手里是一个完整、能跑的 agent，不是一堆零散片段。 这本书分两部分。第一部分把 agent 从 20 行循环建到能上生产 —— 工具、记忆、推理、MCP、多 agent、安全、评估、部署、选型。到那时它「能跑」。第二部分（企业篇）回答一个不同的问题：怎么让它值得被放进一家公司。这两件事的差距，不是一个更强的模型，而是一整层工程 —— 让 agent 可信地、规模化地、在别人的数据上、留得下审计地行动。这一层有八根支柱：身份鉴权、带权限的检索、对抗性安全、治理审计、常设评测、失败工程、控制平面、多租户。它们不是功能清单，是「能跑」到「企业级」之间那道差集。

— I

Agent 不是更大的 prompt.

把 prompt 写长、把对话拉长，都不会变成 agent。分界只有一条：下一步是谁决定的。 Anthropic 把这类系统分两种：workflow 是「LLM 和工具被预定义的代码路径编排」，agent 是「LLM 自己动态决定流程和工具用法」。1注 1Anthropic · 「Building Effective Agents」（Erik Schluntz、Barry Zhang，2024-12-19）—— 区分 workflow（LLM 与工具被预定义代码路径编排）与 agent（LLM 自己动态决定流程与工具）；建议「find the simplest solution possible」，只在复杂度确实改善结果时才加。并给出取舍：workflow 为定义清晰的任务提供可预测性与一致性，agent 以更高成本与误差累积（compounding errors）换灵活性 —— 宜配沙箱测试与护栏、在可信环境运行。区别不在规模，在自主权 —— 流程图是你写死的，还是模型在运行时自己挑的。 多数人以为自己要的是 agent，其实要的是 workflow。Anthropic 的建议很直接：先找最简单的方案，只在复杂度确实改善结果时才加。1注 1Anthropic · 「Building Effective Agents」（Erik Schluntz、Barry Zhang，2024-12-19）—— 区分 workflow（LLM 与工具被预定义代码路径编排）与 agent（LLM 自己动态决定流程与工具）；建议「find the simplest solution possible」，只在复杂度确实改善结果时才加。并给出取舍：workflow 为定义清晰的任务提供可预测性与一致性，agent 以更高成本与误差累积（compounding errors）换灵活性 —— 宜配沙箱测试与护栏、在可信环境运行。一个能用固定步骤说清的活，写成 agent 只会更慢、更贵、更难调。

— II

Agent 是一个循环.

剥掉所有框架，agent 就是一个循环：感知、决策、行动、观察，然后再来。 每一轮，模型看到目标和当前的观察，决定调哪个工具；工具的结果回灌成下一轮的观察，直到任务完成或触发停止条件。ReAct 把这个循环写成「推理和行动交替」。2注 2Yao et al. · 「ReAct: Synergizing Reasoning and Acting in Language Models」（2022，arXiv:2210.03629）—— 把推理（reason）与行动（act）交替成一个循环，是 Agent 循环的奠基论文之一。用伪代码写出来就这么短： 
while not done:
    decision = model(goal, observations)   # 决策：下一步做什么
    if decision.is_final:                   # 模型认为完成了
        return decision.answer
    result = run_tool(decision.tool, decision.args)  # 行动
    observations.append(result)             # 观察，喂回下一轮

Agent 的本质：一个循环

循环本身很小 —— 这就是为什么第二章用 20 行代码就能写出一个能工作的 agent。难的不是循环，是循环里的每一格：工具怎么定义、记忆放哪、推理怎么不跑偏、安全怎么兜底。3注 3Lilian Weng · 「LLM Powered Autonomous Agents」（2023-06）—— 把 Agent 拆成 planning / memory / tool use 三块的高引用综述，作者时任 OpenAI 研究员。作为概念地图使用。这本书剩下的章节，就是逐格把它做实。 这套「循环外面的每一格」，2026 年的行业有一个统一的名字：harness —— 包住模型的全部运行时工程，循环、工具、上下文管理、恢复策略都算。它的分量，Anthropic 自己测过：即便 Opus 4.5 这样的前沿编码模型，跑在官方 Agent SDK 的循环里、跨多个上下文窗口，只给一句高层 prompt，开箱也造不出一个生产质量的 web 应用 —— 模型没变，差距全在 harness 给没给它结构。6注 6Anthropic · 「Effective harnesses for long-running agents」（2025-11-26）—— harness 决定长时程表现的实测：「Out of the box, even a frontier coding model like Opus 4.5 running on the Claude Agent SDK in a loop across multiple context windows will fall short of building a production-quality web app if it's only given a high-level prompt」（开箱状态下，即便 Opus 4.5 这样的前沿编码模型，只给一句高层 prompt 也造不出生产质量的 web 应用）；解法是给结构 —— 初始化 agent、feature list、增量推进。所以行业的注意力正在从「谁的模型强」移向「谁的 harness 能把模型的强兑现」：模型一年一跳，harness 才是同代产品真正拉开差距的那一层。Anthropic 的年度趋势报告把这场转移压成一句 ——「软件开发正在从写代码，转向编排写代码的 agent」。7注 7Anthropic · 「2026 Agentic Coding Trends Report」—— 年度趋势坐标系，主题句：「Software development is shifting from writing code to orchestrating agents that write code」（软件开发正在从写代码，转向编排写代码的 agent）。截至 2026-07。这本书教你亲手搭的，正是这一层。

— III

什么时候不该建 Agent.

agent 不是默认选项，是最后选项。能用一次 LLM 调用解决的，别上循环。 循环是有代价的：每一轮都可能跑偏，多轮意味着更多 token、更高延迟、更难复现的 bug。判断标准是步骤数固不固定 —— 步骤固定、路径已知，那是 workflow 或一个函数；步骤数取决于中间结果（比如「修一个还不知道在哪的 bug」），才轮得到 agent。1注 1Anthropic · 「Building Effective Agents」（Erik Schluntz、Barry Zhang，2024-12-19）—— 区分 workflow（LLM 与工具被预定义代码路径编排）与 agent（LLM 自己动态决定流程与工具）；建议「find the simplest solution possible」，只在复杂度确实改善结果时才加。并给出取舍：workflow 为定义清晰的任务提供可预测性与一致性，agent 以更高成本与误差累积（compounding errors）换灵活性 —— 宜配沙箱测试与护栏、在可信环境运行。 把这条判断展开，就是 2026 年通行的决策框架：步骤能预先枚举、判定标准明确、错了代价高的活，交给确定性工作流 —— 它给你可预测和一致；路径没法预先写死、要一边探索一边调整的活，才交给自由循环的 agent —— 它拿更高的成本和会累积的误差换灵活性，所以要配上沙箱测试和护栏、放在可信的环境里跑。1注 1Anthropic · 「Building Effective Agents」（Erik Schluntz、Barry Zhang，2024-12-19）—— 区分 workflow（LLM 与工具被预定义代码路径编排）与 agent（LLM 自己动态决定流程与工具）；建议「find the simplest solution possible」，只在复杂度确实改善结果时才加。并给出取舍：workflow 为定义清晰的任务提供可预测性与一致性，agent 以更高成本与误差累积（compounding errors）换灵活性 —— 宜配沙箱测试与护栏、在可信环境运行。而真实的生产系统大多两者都有：工作流做骨架，把其中开放式的子任务挖出来，交给 agent 去填。这本书把 agent 这一格教扎实，是为了让你把它嵌对位置 —— 不是把所有东西都改写成 agent。 反过来，什么时候它才值得建？OpenAI 的实践指南给了三类信号：要细腻判断（带例外、看情境的决策）、规则多到难维护、或重度依赖非结构化数据 —— 它把规则引擎比作一张清单，把 agent 比作一个会权衡情境的老练调查员。三样都不沾，确定性方案就够了。4注 4OpenAI · 「A Practical Guide to Building Agents」（2025-04）—— 何时该建 agent 的三类信号：需细腻判断、规则多到难维护、重度依赖非结构化数据；并把规则引擎比作清单、把 agent 比作一个会权衡情境的老练调查员。 所以这本书每一章都会先问一句「这一格值不值得建」，再教你怎么建。建得出来和该不该建，是两回事 —— 把这条记到每一章里。 这条「先问值不值」背后，是 AI 七十年的苦涩教训：能随算力扩展的通用方法（搜索与学习）终究大幅胜过人工堆进去的领域知识。落到 agent —— 拿不准时，把判断交给模型的通用推理加工具，别用一摞写死的逻辑去模拟它。Sutton 的原话是「我们要的是能像我们一样去发现的 AI，而不是装着我们已发现之物的 AI」。5注 5Richard Sutton · 「The Bitter Lesson」（2019-03-13）—— AI 七十年最大的教训：能随算力扩展的通用方法（搜索与学习）终究大幅胜过人工编入的领域知识；「我们要的是能像我们一样去发现的 AI，而不是装着我们已发现之物的 AI」。落到 agent：靠模型通用推理 + 工具，别堆手写逻辑。 动手 · 在写任何代码之前，先做一次分类：
01

写下 3 个你想用「agent」解决的真实任务

从你自己的工作里挑，越具体越好（不是「帮我处理邮件」，是「每天把 X 类邮件归类并起草回复」）。
02

给每个任务贴一个标签

三选一：(a) 其实一次 LLM 调用就够、(b) 是固定步骤的 workflow、(c) 步骤数不固定、真需要 agent。
03

数一数有几个真落在 (c)

大概率多数是 (a) 或 (b)。剩下真正属于 (c) 的，才是你读这本书要建的东西 —— 其余的，省下循环的钱和麻烦。

把 prompt 写长不会变成 agent， 让它自己决定下一步才会。.

A longer prompt isn't an agent; letting it decide the next step is..

Aklman Library

— 讨论

讨论.

评论区初始化中…