面向程序员 · Agent 基础认知课

Agent 入门：会规划和执行的 AI 助理

普通大模型像一个会回答问题的人，Agent 更像一个能接任务、拆步骤、调用工具、观察结果并继续推进的助理。它的核心不是“会聊天”，而是围绕目标完成一串动作。

有目标 不是随便聊天，而是围绕用户给定目标持续推进。

会规划 把大任务拆成可执行的小步骤，并决定先后顺序。

能执行 通过工具、知识库、代码、API 或人工确认完成动作。

能调整 看执行结果是否符合预期，失败时换方案或请求补充信息。

Agent loop plan → act → observe

目标 “生成一版商品导入失败明细 PRD。”

→

规划澄清范围、查资料、梳流程、列字段、写验收。

执行调用知识库、读取接口文档、生成 PRD 草稿。

→

观察检查缺口、风险、冲突，再补充和修订。

LLM
理解和生成

Tools
查和做

Policy
控制边界

01 · 先给定义

Agent 是能围绕目标自主推进步骤的 AI 助理

这里的“自主”不是无限制地乱做事，而是在系统设定的权限、工具和流程内，自己判断下一步该做什么。

Goal

目标驱动

Agent 不是只回答一句话，而是围绕一个目标持续推进，直到产出可交付结果或遇到阻塞。

Plan

任务拆解

把复杂目标拆成小步骤，例如先查资料、再分析、再生成、最后自检。

Act

工具执行

需要实时数据或确定性动作时，调用工具、知识库、文件系统、API 或业务流程。

Observe

结果反馈

看工具返回、检查中间产物、识别失败原因，再决定继续、修正或追问。

一句话面试版 可直接背

Agent 是基于大模型的任务执行系统。它不仅能理解和生成文本，还能围绕目标进行规划、调用工具、观察结果、调整下一步，并在安全边界内完成多步骤任务。

02 · 需求背景

越复杂的任务，越需要 Agent 来组织过程

简单问答用聊天模型就够了。复杂任务需要多轮信息收集、多步操作和中间检查，这时 Agent 的价值会明显。

简单任务

一次回答即可

比如解释一个概念、润色一句话、总结一段文本。任务边界清楚，不需要查外部系统，也不需要持续执行。

复杂任务

需要连续推进

比如排查线上问题、生成 PRD、整理竞品分析、写测试计划。需要拆步骤、查资料、调用工具和做质量检查。

企业里常见 Agent 场景 落地

1研发助手：读代码、查日志、定位错误、生成修复建议和测试用例。
2产品助手：根据需求描述、知识库和接口文档生成 PRD。
3客服助手：查订单、查知识库、生成回复、必要时创建工单。
4运营助手：收集数据、分析反馈、生成报告、给出下一步动作。

03 · 概念区分

Agent 不是单纯的 LLM，也不是一个工具

Agent 通常由 LLM、Prompt、Tool、RAG、MCP、Skill、权限和运行时共同组成。它是一个系统，不是单个能力。

LLM

大脑

负责理解、推理、生成和选择下一步。它是 Agent 的核心能力之一，但不是完整 Agent。

Tool

手脚

负责查资料、调接口、跑命令、写文件、创建工单等具体动作。

Skill

工作手册

告诉 Agent 遇到某类任务时该按什么流程做、用什么资料、怎么验收。

Agent

执行系统

把目标、模型、工具、资料、流程和安全策略组织起来，完成多步骤任务。

普通聊天和 Agent 的区别 关键

维度	普通聊天	Agent
目标	回答当前问题	完成一个多步骤任务
过程	一次或少量对话	规划、执行、观察、调整
外部能力	通常只基于上下文回答	可调用工具、知识库、API、文件和工作流
质量控制	主要看最终回答	还要看步骤、工具调用、权限、日志和交付物

04 · 核心闭环

Agent 的基本循环：Plan、Act、Observe、Adjust

这条闭环是理解 Agent 的关键。它不是一次生成到底，而是边做边看结果，再决定下一步。

1 Plan 理解目标，拆任务，决定需要哪些信息和工具。

2 Act 执行一个动作，例如检索、调用工具、生成草稿、跑测试。

3 Observe 读取工具结果、错误信息、中间产物和外部反馈。

4 Adjust 根据结果修正计划，补资料、换工具或追问用户。

5 Deliver 达到质量标准后，输出最终答案或交付物。

agent loop 伪代码

goal = "生成商品导入失败明细 PRD"
state = collect_context(goal)

while not done(state):
  plan = make_next_step(goal, state)
  action = choose_action(plan)
  result = execute(action)
  state = observe_and_update(state, result)

  if needs_user_input(state):
    ask_clarifying_question()

return final_deliverable(state)

05 · 目标边界

Agent 做得好不好，先看目标有没有说清楚

目标越模糊，Agent 越容易跑偏。好的任务输入要包含目标、范围、约束、输出格式和成功标准。

差的目标

“帮我优化一下系统”

不知道优化哪个系统、面向谁、解决什么问题、输出什么结果，也不知道是否允许查资料、改代码或调用工具。

好的目标

“基于现有商品导入流程生成 PRD”

明确要查现有文档和接口，输出 PRD，重点覆盖失败明细展示、字段、权限、异常处理和验收标准。

给 Agent 的目标说明模板 可复制

字段	说明
目标	这次最终要完成什么。
范围	做哪些，不做哪些。
资料	可以查哪些文档、知识库、系统或接口。
约束	权限、时间、格式、业务规则、不能触碰的动作。
验收	怎样判断结果完成且质量达标。

06 · 任务规划

规划不是把话说长，而是把事情拆到能执行

好的计划要能指导行动。每一步都应该对应一个可观察的动作或产物。

拆步骤

从大目标拆成小任务

例如“生成 PRD”可以拆成澄清需求、查现状、梳流程、列字段、写验收、复核风险。

定顺序

先依赖，后产出

不要先写结论再查资料。应先收集事实，再生成结构化产物。

设检查点

每一步都要能验收

查资料要有来源，生成草稿要能检查章节，调用工具要看返回结果。

good plan example 计划示例

Plan:
1. Clarify target users, business scope, and output format.
2. Retrieve current product import PRD and API schema.
3. Compare existing behavior with the new failure-detail requirement.
4. Draft PRD sections: background, goals, user flow, data fields, edge cases.
5. Validate against checklist: permissions, error states, analytics, acceptance criteria.
6. Return final PRD with assumptions and open questions.

07 · 执行能力

Agent 需要工具，因为真实任务不只靠说

工具让 Agent 从“会回答”变成“能查、能算、能验证、能触发流程”。但工具执行必须受权限和策略控制。

检索工具

查资料

搜索知识库、读取文档、查代码、查历史需求，用于补充事实依据。

业务工具

查系统

查订单、查库存、查会员、查工单，获取实时业务状态。

执行工具

做动作

创建工单、发送通知、生成文件、跑测试。高风险动作要人工确认。

校验工具

检查结果

运行测试、检查 JSON、验证链接、扫描格式，避免只靠模型自我感觉。

执行边界 重要

Agent 可以决定“我需要调用哪个工具”，但真正执行前，系统要检查参数、权限、风险级别和用户确认。尤其是写操作，不能让模型自由执行。

08 · 观察调整

Agent 的强点不是不犯错，而是能发现问题并修正

执行后要看结果。工具失败、资料冲突、参数缺失、答案不完整，都应该进入下一轮调整，而不是假装完成。

观察工具结果 调用是否成功、返回是否为空、字段是否完整、是否有错误码。

→

判断下一步 继续执行、换工具、补参数、追问用户，或说明当前不能完成。

观察中间产物 草稿是否缺章节，引用是否有来源，结论是否超出资料。

→

修正产物 补充资料、重写结构、标记假设、列出风险和待确认问题。

常见观察信号 Debug

1工具返回空：可能查询词错、权限不足、数据不存在。
2资料冲突：需要列出冲突来源，而不是直接选一个。
3参数缺失：应该追问用户，不能自己编参数。
4结果不达标：回到计划，补步骤或换方法。

09 · 上下文和记忆

Agent 需要知道当前状态，但不能把所有东西都塞进上下文

上下文负责让 Agent 记住目标、计划、工具结果和中间产物。记忆则用于跨任务复用偏好、历史事实或长期知识。

任务上下文

本次任务必须知道

目标、范围、用户输入、当前计划、工具返回、中间产物。

短期状态

执行过程中的进度

哪些步骤已完成、哪些工具调用失败、哪些问题待确认。

长期记忆

跨任务复用的信息

用户偏好、团队规范、常用模板、系统背景。要可更新、可删除、可审查。

上下文污染

过多信息会干扰判断

无关资料、过期信息、错误历史会让 Agent 做出错误决策。

记忆设计原则 克制

不是所有对话都要长期记住。只有稳定、可复用、经过用户或系统确认的信息才适合进长期记忆。敏感信息要谨慎，最好有权限、过期时间和删除机制。

10 · 安全护栏

Agent 越能执行，越需要边界

普通回答错了，最多是信息质量问题；Agent 如果执行错了，可能真的改数据、发通知、删文件或影响业务流程。

必须有的护栏

1工具权限：按用户、角色、租户和数据域判断。
2动作分级：只读、低风险写、高风险写分开处理。
3人工确认：退款、删除、外发、批量修改必须确认。
4审计日志：记录目标、计划、工具、参数、结果和 traceId。

危险设计

1让 Agent 直接拥有管理员权限。
2把模型输出的参数直接拼接进 SQL 或命令。
3高风险动作没有确认和幂等控制。
4没有日志，出错后无法复盘执行链路。

agent guard 策略示例

before_agent_action(action, user):
  assert action.tool in allowed_tools(user.role)
  assert validate_arguments(action.arguments)
  assert check_data_scope(user, action.arguments)

  if action.risk_level == "high":
    return require_user_confirmation(action)

  return execute_with_audit_log(action, user)

11 · 架构模式

Agent 不一定越复杂越好，先从可控模式开始

很多企业场景不需要完全开放式 Agent。稳定流程、有限工具、明确检查点，往往比“全自动自主探索”更可靠。

Workflow Agent

固定流程型

步骤基本固定，适合 PRD 生成、报告整理、质检清单。可控性高，适合入门落地。

Planner-Executor

计划执行型

先生成计划，再按步骤执行。适合任务复杂但边界清楚的场景。

ReAct

思考行动循环

围绕“想一步、做一步、看结果”推进，适合需要不断观察反馈的任务。

Multi-Agent

多角色协作

多个 Agent 分工协作，例如产品、研发、测试、评审。但复杂度和治理成本更高。

入门建议 务实

先做固定流程型 Agent，再逐步加入工具、观察、重试和人工确认。不要一开始就做全自动多 Agent 系统，否则调试和安全治理都会很困难。

12 · 评测指标

评测 Agent，要拆开看目标、过程和结果

只看最终回答不够。Agent 的价值来自过程，风险也来自过程，所以要评测每个关键环节。

01 目标理解

是否正确识别用户目标、范围、约束和输出标准。

02 计划质量

步骤是否合理，是否遗漏关键资料、工具和检查点。

03 执行正确

工具是否选对，参数是否正确，权限和风险是否受控。

04 交付质量

最终产物是否完整、准确、可用，并且能解释依据和假设。

常见失败类型 排查

1计划看起来完整，但没有真正执行关键步骤。
2工具选错或参数错，导致后续结论建立在错误数据上。
3遇到失败不追问、不重试，直接编一个看似完整的结果。
4没有记录执行链路，无法复盘为什么得出某个结论。

13 · 企业案例

用 Agent 生成“商品导入失败明细 PRD”

这个案例可以把 Agent、RAG、Tool Calling、MCP、Skill 串起来，适合面试时讲企业落地。

目标输入 用户说：“产品录入时批量导入失败，需要展示失败明细，帮我生成 PRD。”

Agent 规划 拆成澄清范围、查现有导入流程、查错误码、查接口字段、生成 PRD、质量自检。

工具执行 调用知识库检索、接口 schema 查询、历史 PRD 查询，必要时向用户追问业务范围。

观察调整 发现接口缺少行级错误字段时，标记为待新增能力，并在 PRD 风险里说明。

最终交付 输出 PRD：背景、目标、用户流程、字段设计、异常处理、权限、埋点、验收标准和风险。

agent task trace 执行轨迹

Goal:
  Generate PRD for product import failure details.

Plan:
  1. Search existing import workflow docs.
  2. Read API schema for import task result.
  3. Extract current error-code rules.
  4. Draft PRD using enterprise template.
  5. Validate fields, edge cases, permissions, analytics.

Observation:
  Current API returns task-level failure count,
  but not row-level error detail.

Adjustment:
  Add backend requirement: expose row index, field name,
  error code, error message, and suggested fix.

这个案例的讲解重点 面试友好

Agent 的价值不是直接写一篇漂亮 PRD，而是能围绕目标把查资料、对齐现状、发现缺口、生成结构化产物和自检串成闭环。它应该明确哪些是事实、哪些是假设、哪些需要业务或研发确认。

14 · 面试问答

回答 Agent，要讲“系统”和“闭环”

面试官问 Agent，通常不是只想听“AI 助理”。要讲出目标、规划、工具、观察、调整和安全边界。

Q1：Agent 是什么？

A：Agent 是基于大模型的任务执行系统。它能围绕用户目标进行规划，调用工具或知识库执行步骤，观察结果，再根据反馈调整下一步，最终交付可用结果。

Q2：Agent 和普通聊天机器人有什么区别？

A：普通聊天机器人主要回答当前问题，Agent 更强调完成任务。它会拆解目标、维护状态、调用工具、处理失败、做质量检查，适合多步骤任务。

Q3：Agent 的核心组成有哪些？

A：通常包括大模型、系统提示词、任务规划器、工具调用能力、上下文和记忆、观察反馈机制、安全策略、日志和评测体系。不同项目可以简化或扩展。

Q4：什么时候适合用 Agent？

A：当任务需要多步骤执行、外部工具、动态决策和中间反馈时适合用 Agent。比如故障排查、PRD 生成、客服工单处理、代码分析。如果只是简单问答，用普通 LLM 或 RAG 就够了。

Q5：Agent 落地最大的风险是什么？

A：主要风险是工具误用、权限越界、计划跑偏、错误结果被继续放大，以及缺少审计日志。解决方式是限制工具权限、设置人工确认、做参数校验、记录执行链路，并对过程和结果做评测。

15 · 练习和速查

练习目标：能把一个任务拆成 Agent 可执行闭环

学完这一课，不要求马上写复杂系统，但要能把“目标、计划、工具、观察、交付”讲清楚。

练习 1

设计客服 Agent

用户问“订单为什么没发货”，列出目标、计划、需要调用的工具、观察点和最终回答边界。

练习 2

设计排障 Agent

从“接口 500 增多”出发，拆出查监控、查日志、查发布记录、提出假设、验证根因的流程。

练习 3

设计 PRD Agent

把需求描述转成 PRD，列出需要的知识库、接口文档、Skill、校验清单和人工确认点。

一页速查卡 复习

1Agent 是会围绕目标规划和执行的 AI 助理，不只是聊天模型。
2核心闭环：Plan、Act、Observe、Adjust、Deliver。
3Agent 由 LLM、Prompt、Tool、RAG、MCP、Skill、上下文和安全策略组成。
4适合多步骤、需工具、需反馈、需交付的复杂任务。
5落地时要控制工具权限、人工确认、日志审计和质量评测。