企业官网建设流程全解析

设计公司网站 唐山,龙南城市建设局网站,网站建设百度认证图片,久久建筑网怎样Google AI Agent 白皮书拆解#xff08;1#xff09;#xff1a;从《Introduction to Agents》看清 Agent 的工程底座 摘要#xff08;先看结论#xff09; 一句话结论#xff1a;Agent 不是“更会聊天的 LLM”#xff0c;而是一个可构建、可运行、可治理的软件工程系…Google AI Agent 白皮书拆解1从《Introduction to Agents》看清 Agent 的工程底座摘要先看结论一句话结论Agent 不是“更会聊天的 LLM”而是一个可构建、可运行、可治理的软件工程系统用模型在可重复的控制回路里做事并在工具、上下文、部署与治理上补齐“生产级能力”。落地路径先把 Level 1事实闭环跑稳再做 Level 2上下文工程最后才谈多智能体与规模化治理。最大风险多数团队“只做了模型 工具”缺了编排层与运行时导致 Demo 很美、生产必翻车。1. 白皮书背景Google 把 Agent 讨论拉回“工程全生命周期”2025 年 11 月 10–14 日Google 连续 5 天发布 5 篇 AI Agent 白皮书并开源到 Kaggle。它的意义不在于“提出一个新概念”而在于把行业常见的“Prompt 工具拼装”拉回到软件工程语境怎么构建组件分层、接口契约、边界与职责怎么评估数据集、评测口径、LM Judge、回归机制怎么运维可观测、灰度、回滚、成本与 SLA怎么部署运行时、扩缩容、权限与审计名词小抄便于快速对齐口径接口契约模块/服务之间的“约定”包括输入输出、错误码、幂等/超时语义、版本兼容等契约越清晰集成与测试越可控。评测口径评估到底“测什么、怎么判对错”的规则集合指标定义、样本范围、阈值、打分方式、统计口径。LM Judge用另一个或同一个大模型充当“裁判”来给答案打分/判胜负如有用性、事实性、遵循指令、风格一致性。常见做法是统一 Rubric 多轮/多评审采样 和人工标注对齐降低主观漂移与偏见。回归机制把历史通过的用例/数据集固化成自动化回归确保模型、Prompt、工具、编排或依赖升级后关键指标不倒退。灰度分批/分流上线按比例、按人群、按区域等观察指标与告警异常时可快速停止扩散。SLAService Level Agreement服务等级协议对外承诺的可用性/延迟/错误率/吞吐等目标以及监控口径、补偿与违约处理。对 Agent 系统而言SLA 往往还需要把“模型调用不确定性、工具依赖波动、成本预算”一起纳入约束。金句Google 把 Agent 的焦点从“模型能不能”转向“系统稳不稳、控不控、能不能规模化”。这一点对做平台、做架构、做产品落地的人尤其重要你终于有了一张“官方工程地图”不再靠零散的经验拼图。2. Agent 的本质不是 LLM而是“四件套”的工程系统很多团队以为“接上一个大模型 给它几个工具”就是 Agent。白皮书的核心观点恰恰相反Agent Model Tools Orchestration Layer Deployment / Runtime四件套缺一不可少一件都很难称为“可上生产的 Agent”。┌──────────┐ ┌────────┐ ┌──────────────────────┐ ┌───────────────────┐ │ Model │ │ Tools │ │ Orchestration Layer │ │ Deployment/Runtime│ └──────────┘ └────────┘ └──────────────────────┘ └───────────────────┘2.1 Model大脑但不是 Agent 本身模型负责理解目标、推理、生成计划、做选择。但模型只是一种能力源头并不具备“把事情办完”的工程结构。把模型当 Agent 的全部会导致两个典型问题只能建议、不能落地没有动作闭环漂移不可控没有状态机与边界约束2.2 Tools手让 Agent 接触现实世界工具让 Agent 从“说”变成“做”查数据、调用 API、执行代码、写入系统、触发工作流。没有工具复杂任务只会停留在“口头建议”。2.3 Orchestration Layer神经系统最容易被忽略但最关键编排层决定 Agent 是否像一个系统在运转而不是“一次性生成”。它负责跑 think–act–observe 循环状态机管理上下文与任务状态短期轨迹/长期记忆决定何时思考、何时调用工具、何时停下来问人这层做不好你会看到“工具乱用、参数乱编、反复查询、死循环、越权动作”等所有生产事故。2.4 Deployment/Runtime身体决定能不能长期在线生产级 Agent 需要“长期运行、可扩缩容、可监控、可审计”。多数团队做 Demo 时默认忽略运行时没有任务队列、没有超时重试、没有配额、没有隔离沙箱、没有审计——上线就爆。金句Agent 的关键不是“能生成文本”而是“用 LLM 在循环里做事”——本质是持续运转的控制回路。3. Agent 如何做事五步循环机制从目标到落地把 Agent 和 ChatBot 区分开的“分水岭”不是语言能力而是是否先查事实、再行动、再回写上下文。3.1 五步循环拆解每一轮循环都在做同一件事输入任务上下文 → 决策 → 行动 → 观察 → 更新上下文 → 进入下一轮。Get Mission获取目标用户输入/系统触发Scan the Scene扫描上下文历史对话、可用工具、权限、已知事实Think it through形成可执行计划步骤化、带约束Take Action通过编排层调用工具执行Observe and Iterate把结果回写上下文判断下一步/结束条件金句Agent 的核心不是“输出漂亮文本”而是“用可重复的循环把任务一步步办完”。3.2 一个小示意图脑内就能画出来[Mission] → (Scan Context) → (Plan) → [Tool Call] → (Observe Result) ↑----------------------------------------------------------↓ (Update Memory / State) → Next Iteration你做架构时最应该盯住的是循环的状态边界在哪里结束条件是什么异常如何处理每一步的输入输出能否审计4. Agent 分级Level 0–4每升一级都是“一整套工程负担”白皮书给了一个非常实用的分级体系它不是为了炫技而是用来界定承诺与成本。4.1 Level 0纯推理系统只靠模型内部知识推理不接现实世界。能给建议但容易胡猜无法闭环。4.2 Level 1连接问题解决者最推荐的落地点接入工具先查事实再回答。关键工程点是工具契约稳定参数、返回结构、错误码、权限边界要明确。4.3 Level 2上下文工程专家主动管理上下文拆目标、压噪音、做摘要、避免注意力稀释。这里开始进入“工程细活”记忆结构、召回策略、窗口预算。4.4 Level 3协作多智能体通过 Coordinator 分解任务派发给专家 Agent 协作完成。好处是可测可维护代价是需要任务通信协议、状态聚合、跨 Agent 治理。4.5 Level 4自我扩展系统能发现能力缺口、动态创建工具/Agent。想象空间巨大但治理成本爆炸权限、审计、资产管理、行为边界都难。金句Level 不是炫技而是你的系统承诺——别一上来就做 Level 3/4治理跟不上必翻车。落地建议先把 **Level 1事实闭环**跑稳再上 Level 2上下文工程。5. 模型选型别看榜单看“业务目标三张账”Agent 的模型选型不是“谁更强”而是“谁在你的任务集上更合适”。白皮书给出的思路非常工程化5.1 三步选型法先定义业务 KPI目标达成率、满意度、工具成功率、单次成本、P95 延迟把 KPI 映射成离线任务集Golden Set你自己的真实任务样本用同一脚本跑质量/延迟/成本三张账同口径对比才能做决策5.2 Agent 场景的两项关键能力多步推理稳定性长链路不漂移、不自相矛盾可靠工具使用不编参数、会用返回值、遇错能自救或停下来问人5.3 工程策略多模型路由 持续评测重推理/高价值强模型轻任务/高频快模型通过路由与预算控制把钱花在“刀刃步骤”上金句Agent 选型不是“选一个最强模型”而是“选一个最合适的组合点”。6. 工具与人类在环能力做成“可复用接口”风险关进“笼子里”6.1 工具的类型地图检索类RAG企业文档、知识图谱结构化事实、Search实时信息结构化操作NL2SQL / BI 查询强调可控、可审计执行类发邮件、排会议、改配置必须有清晰契约与权限代码执行沙箱跑 Python/SQL必须限资源、控权限、可审计名词小抄把“看起来像黑话”的东西翻译成人话BIBusiness Intelligence商业智能一套“让业务自助看数”的数据分析体系通常包括数据仓库/数据集市、语义层指标口径、报表/仪表盘、权限与审计等。它解决的是“同一指标到底怎么算、谁能看、怎么复用”的工程化问题而不只是跑一条 SQL。BI 查询面向业务分析场景的查询/取数方式典型特征是“口径先于查询”。你可能不是直接写 SQL 去扫明细表而是通过语义层的指标如 GMV、转化率、留存和维度时间、地区、渠道来切片、下钻、聚合从而保证可控、可审计、可复现。NL2SQL vs BI 查询NL2SQL 更像“把自然语言翻成 SQL”BI 查询更像“在既定指标口径与权限框架下做取数/分析”。前者的主要风险是生成 SQL 不可靠、越权扫表后者通过语义层与权限把风险前置收敛。沙箱Sandbox让 Agent 可以“执行代码但不伤系统”的隔离运行环境。大模型本身不会真正执行 Python/SQL通常是编排层把代码交给一个受控执行器本地或远端运行然后把结果回传给模型。沙箱怎么实现工程视角常见实现是把执行器跑在容器/轻量虚拟机/wasm 等隔离边界里并强制施加资源与权限约束例如CPU/内存/磁盘配额、执行超时、网络出站默认禁用或白名单、只读文件系统/工作目录隔离、系统调用过滤如 seccomp、无特权用户、结果与日志可审计。类似 Trae 的“沙箱体验”从哪来你在 IDE 里看到的代码执行/工具调用一般也是“宿主IDE/Agent 隔离执行器”的架构宿主负责把任务与输入发给执行器执行器在受限环境里运行并回传 stdout/stderr、产物与指标宿主再把这些作为“可追溯证据”喂回给模型用于下一步决策与回归排查。6.2 人类在环HITL是“安全阀”不是体验负担什么时候必须刹车让人确认信息不足缺日期、缺收件人、缺金额高风险动作发信、改数据、付款、触发不可逆操作权限边界不明确工具返回“可能影响生产”金句工具不是越多越好——是把能力做成“可复用接口”把风险关在“笼子里”。7. 编排层 Orchestration决定系统稳不稳不是模型越大越稳编排层的核心思想可以用一句话概括把“模型的提议”与“系统的批准”分开。7.1 编排层三大职责状态机驱动 think–act–observe 循环记忆管理短期轨迹不重复查、长期检索按需召回节奏控制规则优先模型补位明确何时调用工具/何时停下来问人7.2 设计光谱确定性工作流 vs 动态规划确定性工作流 LLM 插件可治理、可回归适合流程固定的业务LLM 驱动动态规划覆盖复杂任务但轨迹难控需要更强可观测与安全策略7.3 生产级硬标准可观测性没有 Traces/Logs你根本不知道 Agent 为什么翻车是工具失败是上下文污染是规划不当是越权所以编排层必须内建Trace每一步决策/工具调用结构化日志输入、输出、错误码、耗时指标成功率、重试率、循环次数、成本、P95金句真正把 Agent 坐稳的不是让模型更聪明而是让编排层更会“管节奏、管状态、管边界”。8. 上下文与记忆工程Agent 是“上下文窗口的策展系统”很多 Agent 不稳定根因不是模型不行而是上下文被喂成“一锅粥”。白皮书给了非常清晰的上下文六要素8.1 上下文六要素系统指令角色、约束用户输入任务触发Session History多轮连贯长期记忆偏好、历史决策Grounding 知识权威事实工具清单 已做动作及结果避免重复、可审计8.2 记忆二分法短期 vs 长期短期记忆任务工作台行动轨迹、工具结果、当前计划长期记忆跨对话硬盘RAG 检索按需召回不炸窗口金句很多 Agent 不稳定不是模型不行是上下文被喂成“一锅粥”——注意力被噪声稀释了。9. 多智能体别造“超人”造“专家团队”Multi-Agent 的价值不是“更炫”而是把复杂度拆成可治理模块9.1 三大收益聚焦单 Agent 职能单一决策更可控可测每个专家 Agent 有专属评测集可维护问题易定位、易回归9.2 常见四种协同模式Coordinator拆目标给专家非线性任务Sequential流水线步骤固定Iterative Refinement生成-批判-再生成保质量HITL 停顿点高风险动作前强制刹车金句Multi-Agent 不是把问题变复杂而是把复杂度拆成模块——把不确定性关进可治理边界。10. Agent Ops让“概率系统”可管、可迭代Agent 的输出不是确定程序而是概率分布同样输入可能走不同路径、用不同工具、生成不同计划。传统 DevOps 不够用需要 Agent 专属闭环。名词小抄Ops / DevOps 到底是什么意思OpsOperations运维让系统“稳定在线”的一整套工作与能力目标是可用、可控、可恢复。常见范围包括发布与回滚、监控告警、容量与成本、故障应急、变更管理、权限与审计、SLA 保障等。DevOps一种把“开发Dev”与“运维Ops”打通的工程方法论与组织实践核心不是某个工具而是通过自动化流水线、基础设施即代码、可观测性与反馈机制让交付更快且更稳定缩短从代码变更到线上价值的周期同时降低失败率、提升可恢复性。为什么说传统 DevOps 不够用传统系统的行为更接近确定性程序而 Agent 是概率系统线上表现会随模型版本、采样随机性、上下文、工具依赖波动而漂移因此需要把“评测含 LM Judge/人工对齐 轨迹Trace 回归集沉淀 灰度与回滚策略”做成日常闭环这就是 Agent Ops 关注的重点。10.1 三步落地法KPI 先行先定义“什么叫更好”LM Judge 评测用强模型按规则打分统一口径指标驱动开发不达标不上线灰度验证失败样例沉淀为回归集10.2 关键工具Traces追“为什么翻车”高保真轨迹反馈闭环线上失败 → 沉淀评测样例给系统打疫苗金句Agent Ops 不是 DevOps 重命名——是在“随机系统”上重新发明一套工程闭环。11. 互操作从“能用”到“融入生态”的关键白皮书把互操作分成三条线人机、智能体之间、以及金钱/支付。人机互操作Chat Bot → 结构化输出驱动 UI→ Computer Use操作界面→ Live Mode实时多模态智能体互操作A2A发现Agent CardJSON 数字名片能力、端点、凭据通信异步任务长任务回传进度区别于一次性工具调用金钱互操作授权、不可抵赖、机器间微支付等机制用于商业闭环金句没有 A2A 标准就做不出可扩展的 Level 3 多智能体生态——别把“连工具”和“连 Agent”混为一谈。12. 安全与治理上生产的硬门槛不是加分项12.1 三大核心风险Rogue Actions自作主张做不可逆动作敏感数据泄露上下文混杂多类信息Prompt Injection恶意指令诱导越权调用12.2 防御纵深两道门硬规则God Rules金额上限、二次确认、API 白名单、最小权限Guard Models识别诱导越权、调用意图变形、注入攻击12.3 规模化治理三件套Agent Identity可验证身份Control Plane统一授权与审计入口Registry资产清单与生命周期管理金句不要把安全寄托在“模型自觉”上——要把安全写进系统结构里。13. 部署与迭代从 Demo 到生产的最后一公里部署的目标不是“能跑”而是“长期运行、可扩展、可监控、可回滚”。13.1 两条部署路径平台化托管如 Vertex AI Agent Engine上手快、能力齐适合先跑通闭环容器化自运维Docker Cloud Run/GKE控制力强但你要自建运维与治理体系13.2 持续迭代保障CI/CD构建、部署、灰度、回滚自动化测试评测集、KPI 回归、安全策略回归金句Agent 上线不是结束——没有 CI/CD 和自动化测试每次改动都是线上赌博。14. 最后总结Day 1 你必须带走的三件事Agent 是四件套工程系统Model Tools 编排层 运行时核心是循环做事think–act–observe 的控制回路而不是一次性回答落地先后顺序Level 1事实闭环→ Level 2上下文工程→ 再谈多智能体与规模化治理压轴金句做 Agent 别沉迷炫技——先把“事实闭环、上下文工程、可观测”这三件事做扎实。15. 最小落地清单把 Demo 变成生产先立约束明确任务边界、结束条件、异常分支与人工确认点HITL先做工具契约参数/返回结构/错误码/权限边界稳定再谈能力扩展先补编排层状态机 上下文/记忆管理 节奏控制规则优先、模型补位先做可观测Trace/结构化日志/核心指标成功率、重试率、循环次数、成本、P95先建回归Golden Set 自动化评测 灰度/回滚把线上失败沉淀为回归集