这不是“某节课的摘录”，而是我对 Agent 产品化的结构化沉淀：从定义、架构、记忆、工具调用，到评估、守护、人机协同与上线治理。核心判断是：Agent 不是更会聊天的模型，而是能在边界内持续完成任务的系统。
一个专业的 Agent 不应只被描述成“会自主思考”。在工程语境里，它更像一个封装好的运行单元：模型负责推理，指令定义边界，工具连接外部系统，记忆提供状态，守护负责风险控制，评估负责持续改进。
决定理解、生成、工具选择与复杂任务分解能力。模型越强，并不自动等于 Agent 越可靠，还需要边界、工具和评估体系。
定义 Agent 的任务、禁止事项、输出格式、判断标准和交互风格。它是产品需求在运行时的具体化。
通过 Function Calling、MCP、浏览器、数据库、搜索或内部 API，让模型可以获取新信息或触发动作。
短期记忆维持当前上下文，长期记忆沉淀用户偏好和业务知识，情景记忆记录任务过程与关键决策。
单 Agent 适合边界清晰任务；多 Agent 适合专业分工。关键选择是“谁拥有最终答案”，以及何时移交。
输入、输出、工具参数和高风险动作都应有检查机制。敏感动作需要人审，而不是让模型自由执行。
产品经理看 Agent，不应只看“能不能回答”，而要看它是否能在明确边界内稳定完成任务：任务成功率、工具选择正确率、人工介入率、错误恢复能力和可追溯性，才是能否上线的判断标准。
原笔记里的“记忆、规划、工具、执行”是好的骨架，但还不够工程化。真正可上线的 Agent 需要把上下文、工具、运行时、评估和治理放进同一张图里。
先定义任务输入、输出、失败条件、不可做事项、成功标准。没有清晰目标，后面的模型和工具都会变成“炫技”。
短期上下文解决当前对话连续性；长期知识通过 RAG、文件检索、用户画像或业务数据库提供事实依据。
让模型把目标拆成步骤，决定是否需要工具，观察工具结果，再调整计划。复杂任务需要限制步数、预算和重试策略。
工具描述要足够清楚，参数要结构化，结果要可校验。工具越多，越需要检索、分组和权限控制。
输入过滤、输出校验、工具调用前后检查、敏感动作审批，是 Agent 从 Demo 走向生产的分水岭。
不要靠主观体验判断 Agent 好坏。要用轨迹记录、人工标注、评测集和线上反馈，持续发现失败模式。
长期记忆的核心难点不是存储，而是“何时写入、写什么、如何召回、如何防止污染”。RAG 是常见方案，但不是所有记忆问题都应该用 RAG 解决。
面向 Agent 的 RAG 需要额外关注：查询改写、混合检索、重排、引用来源、答案置信度、失败兜底，以及工具结果是否能进入下一轮规划。
Function Calling 把工具调用结构化，MCP 进一步把工具、资源、提示词等能力以协议方式暴露出来。工具生态越开放，越要补上权限、确认、日志和异常处理。
Agent 需要知道有哪些工具、何时使用、需要什么参数。
模型按 JSON Schema 或工具协议生成结构化参数。
运行时调用外部 API、MCP Server、数据库或工作流。
工具结果进入上下文，供模型继续判断、追问或下一步行动。
对结果做格式、事实、权限和副作用检查，必要时人审。
适合应用内少量稳定工具。重点是 schema、工具描述、错误返回和二次确认。
通过客户端与服务器的能力协商、工具列表和工具调用，使同一能力被不同 AI 应用复用。
当工具数量很大时，不应一次塞给模型，而应按需求动态检索和加载候选工具。
多 Agent 不是越多越高级。只有当任务需要不同角色、不同工具权限、不同审批策略或不同输出责任时，才值得拆成多 Agent。
适合边界清晰、工具少、风险低的任务。优点是链路短、延迟低；缺点是复杂任务容易失控。
一个主 Agent 保持最终答复权，把专家 Agent 当工具调用。适合需要统一口径的复合任务。
当某个专家需要接管对话或完整任务分支时使用。关键是移交条件、上下文摘要和责任边界。
真正的交付不是做出一次惊艳 Demo，而是让系统在大量真实输入下稳定工作，并且失败时可解释、可恢复、可追责。
明确用户、场景、输入、输出、成功标准、禁止行为和升级路径。
只暴露完成任务必需的工具，先做少而稳，再扩展能力面。
沉淀黄金样本、边界样本、坏例样本，用数据集跑回归。
记录模型调用、工具调用、移交、守护和最终输出，用轨迹定位失败原因。
输入、输出和工具调用都要校验；敏感动作必须进入人工审批。
先在低风险场景上线，观察成功率、人工介入率、失败类型和成本。
把线上失败样本回流到评测集、提示词、工具描述和业务规则。
沉淀权限、审计、版本管理、模型回滚和数据安全机制。
术语表从“课堂速记”调整为面向项目沟通和面试表达的专业词汇表。
内容参考官方文档与一手资料后重新整理为个人知识沉淀，页面中的判断和表达已转化为产品经理视角。