跳到主要内容

AI-Agent全景图

1. 定义与边界​

AI Agent 是一个由大模型参与决策的执行系统。它接收目标或任务，在受控环境中维护状态，动态选择工具，观察工具或环境反馈，并在满足退出条件前持续推进任务。

工程上可以用四个条件判断一个系统是否接近 Agent：

条件说明不满足时通常是什么
目标驱动输入不是单轮问答，而是可完成的任务目标Chatbot
动态决策模型参与选择下一步，而不是完全固定路径Workflow
环境反馈能读取工具结果、错误、测试、用户反馈并调整脚本自动化
行动能力可调用外部工具或系统改变状态RAG 问答或 Copilot

OpenAI 的 agent 指南强调 Agent 能代表用户执行工作流，核心组件是模型、工具和指令。Anthropic 将 agentic systems 区分为 workflow 与 agent：workflow 是预定义代码路径，agent 是模型动态控制流程和工具使用。

2. 为什么重要​

Agent 的价值来自三个工程缺口：

  1. 传统规则系统难以覆盖非结构化输入、例外情况和复杂判断。
  2. 普通 LLM 应用能生成答案，但不能可靠地推进跨系统任务。
  3. 工作流自动化稳定但僵硬，一旦路径、数据或异常增多，维护成本上升。

适合 Agent 的场景通常具备：

  • 任务目标明确，但步骤数量和顺序不固定。
  • 需要在多个工具或数据源之间来回探索。
  • 中间结果可以被环境验证，例如测试结果、订单状态、检索命中、审批结果。
  • 失败可以被限制在沙箱、只读权限、人工审批或可回滚操作内。

不适合 Agent 的场景：

  • 路径固定、规则清晰、输入结构化的审批或批处理。
  • 没有明确成功标准的开放式“帮我优化业务”。
  • 高风险不可回滚动作，却没有审批、审计和回滚机制。
  • 只需要信息检索和摘要，不需要行动。

3. 核心分层​

模型层​

模型负责理解任务、生成推理、选择工具、形成结构化参数、解释观察结果。生产系统不应假设模型永远正确，需要用 schema、校验器、工具错误和评测集限制其行为。

编排层​

编排层决定系统是 workflow、单 Agent loop、图结构还是多 Agent。常见策略：

模式适用场景主要风险
Prompt chaining可分解为固定步骤延迟增加，步骤间错误传递
Routing输入类别清晰路由错误导致后续全部偏离
Parallelization子任务独立或需要投票成本高，聚合逻辑复杂
Evaluator-optimizer有清晰评价标准自评偏差，循环过度
Single Agent工具少、目标集中工具增长后上下文混乱
Multi-Agent领域边界清晰、上下文隔离有价值协调成本、责任不清、调试困难

工具层​

工具是 Agent 与世界交互的接口。它至少应包含：

name: create_refund_request
description: 为符合政策的订单创建退款申请，不直接打款
risk_level: medium
idempotent: true
requires_human_approval: false
input_schema:
  order_id: string
  reason_code: enum
  evidence_summary: string
output_schema:
  request_id: string
  status: enum[pending, rejected, created]
errors:
  - ORDER_NOT_FOUND
  - POLICY_NOT_MATCHED
  - DUPLICATE_REQUEST

工具设计要符合 Agent-computer interface（ACI）原则：名称清晰、参数无歧义、返回结果短而有用、错误可行动、相似工具边界明确。

工具变多之后，不要把全部 schema 常驻 system prompt。任务级步骤、完成定义和触发条件收成 Skill；MCP 继续只做标准化连接。分层与治理见 ../19-Skills与能力平台/README.md。没有 API、必须操作 GUI 时，按 ../20-Computer-Use与浏览器Agent/README.md 选型，不要默认截图点鼠标。

状态层​

状态不是聊天历史的同义词。生产 Agent 至少区分：

状态类型示例用途
会话状态用户身份、偏好、当前对话连续交互
任务状态当前目标、已完成步骤、阻塞点控制执行
工具状态tool call id、参数、结果、错误回放与重试
计划状态当前计划、下一步、弃用计划解释和恢复
记忆长期偏好、项目知识、历史决策跨任务复用
安全状态权限、审批、风险等级最小权限与审计

Anthropic 的 context engineering 强调上下文是有限资源，长任务需要压缩、结构化笔记、按需检索或子 Agent 隔离上下文，而不是无限堆聊天历史。

数据流、控制流与审计流​

很多 Agent 架构图只画“模型调用工具”，但生产系统至少有三条流：

流从哪里到哪里主要问题典型产物
数据流用户/外部系统 -> 上下文 -> 模型 -> 工具结果 -> 状态哪些信息可信、哪些需要脱敏、哪些会进入上下文context packet、observation、state snapshot
控制流编排器 -> 模型决策 -> 策略校验 -> 工具执行 -> 停止判断下一步由谁决定、何时中断、何时终止decision、policy result、pending action
审计流模型/工具/审批/异常 -> trace -> eval/回放失败能否复盘、是否能生成回归样本run id、span、approval record、eval case

4. 架构模式​

单 Agent + 工具​

适合早期版本和目标集中的场景。

优点是简单、可调试、评测边界清楚。缺点是工具过多时会出现选择混乱和上下文污染。

Workflow + 局部 Agent​

确定性系统控制主流程，只在少数环节调用 Agent。

适合金融、客服、企业内部流程等需要强控制的场景。

图结构 Agent​

使用节点、边、状态和中断构建可恢复的复杂流程。LangGraph 这类框架强调 durable execution、persistence、interrupts，适合需要回放、人类审批和长流程恢复的系统。

多 Agent​

适合复杂研究、代码修改、跨职能任务。前提是每个 Agent 有清晰职责、独立工具集和明确交接协议。否则多 Agent 只会把单 Agent 的不确定性放大。

5. 架构判断​

设计 Agent 前先做架构判断，而不是默认上“自主循环”。

判断问题选择倾向理由
任务步骤是否固定Workflow固定流程更便宜、更可审计
是否需要模型基于中间结果选择下一步Agent Loop动态路径是 Agent 的主要价值
是否存在高风险写操作Workflow + HITL + 局部 Agent主流程和审批应由系统控制
工具是否超过 10 个且边界相似先路由/分组，再 Agent直接暴露所有工具会降低工具选择准确率
是否需要长任务恢复图结构/队列 + checkpoint普通 while loop 不能可靠恢复
是否需要多人或多领域协作多 Agent 或 orchestrator-workers前提是职责、交接和评测清晰
是否只是文档问答RAG Chatbot不需要行动循环

架构判断的核心是把“不确定性”放在最小范围：确定性校验、权限、审批、状态机和回滚交给代码；模型只负责难以预先编码的理解、选择、归纳和修正。

6. 工程实现骨架​

def run_agent(task, user, tools, policy, store):
    state = store.create_run(task=task, user=user)

    for step in range(policy.max_steps):
        context = build_context(state, policy.context_budget)
        decision = model.decide(
            instructions=policy.instructions,
            context=context,
            tools=[t.schema for t in tools.allowed_for(user)]
        )

        store.append_span(state.run_id, "model_decision", decision)

        if decision.type == "final":
            output = validate_output(decision.output, policy.output_schema)
            return store.finish(state.run_id, output)

        tool = tools.get(decision.tool_name)
        risk = policy.risk_for(tool, decision.arguments)

        if risk.requires_approval:
            approval = request_human_approval(user, tool, decision.arguments)
            if not approval.granted:
                return store.escalate(state.run_id, approval.reason)

        args = validate_args(tool.schema, decision.arguments)
        result = tool.invoke(args)
        store.append_span(state.run_id, "tool_result", result)
        state = update_state(state, decision, result)

        if should_stop(state, policy):
            break

    return store.fail(state.run_id, reason="max_steps_exceeded")

实现时要把模型调用、工具调用、状态更新、审批、trace 写入做成显式组件，而不是混在一个 prompt 或回调里。

7. 生产实践​

关注点实践
成本设置最大步数、上下文预算、模型路由、缓存和批量评测
延迟将固定路径前置为 workflow，Agent 只处理不确定环节
可观测每次模型调用、工具调用、审批、异常都生成 span
可恢复状态持久化，工具幂等，失败后能从上一个安全点继续
权限按用户、任务、工具、资源四个维度做最小授权
数据敏感信息脱敏，外部内容标记来源和信任级别
发布先只读，再可回滚写入，再放开高风险动作

8. 学习路线与能力闭环​

全景图的学习顺序应该从“能解释控制权”开始，而不是从框架开始。

阶段重点问题产出
1. 边界需求是否真的需要 Agent形态判断表、任务契约
2. 循环Agent 如何感知、决策、行动、反馈最小 Agent Loop
3. 工具工具 schema、错误码、权限如何设计工具注册表和测试样例
3b. 能力封装何时用 Skill 而不是再挂工具或拆 Sub-agentSkill 清单、触发评测、版本
4. 状态长任务如何保存、压缩、恢复state schema、checkpoint
5. 评测如何评任务结果和过程轨迹eval dataset、trace evaluator
6. 安全如何限制越权、注入和泄漏guardrails、HITL、审计
7. 生产如何灰度、监控、回放和治理SLO、告警、回归流程

9. 常见反模式​

反模式表现后果修正
用多 Agent 掩盖任务定义不清角色很多但目标、退出条件不清协调成本上升，成功率不升反降先写任务契约和单 Agent baseline
无限堆上下文所有历史消息都塞入 prompt注意力稀释、成本失控、隐私暴露状态摘要、按需检索、上下文预算
工具返回原始大数据模型自己在几千行日志里找字段误读、超 token、延迟高工具返回结构化摘要和引用
工具边界模糊update_record、modify_record 同时存在工具选择错误命名规范、互斥描述、工具评测
建议态和执行态混淆UI 上看不出是否已经执行用户误解和责任不清明确 draft/pending/executed 状态
忽视 Agent 安全面只做内容安全，不做工具安全注入、越权、数据外泄最小权限、HITL、审计、红队

10. 评测方法​

Agent 评测应同时看最终结果和过程轨迹：

维度指标
任务结果Task Success Rate、一次完成率、人工接管率
工具使用Tool Call Accuracy、参数正确率、无效调用率
过程控制平均步数、最大步数触发率、循环率、超时率
安全越权调用拦截率、敏感数据泄漏率、高风险动作审批覆盖率
成本与体验token 成本、工具成本、端到端延迟、用户修正次数
可维护性回归测试通过率、失败样本修复周期、工具 schema 变更影响

11. 安全与治理​

Agent 的风险高于普通 LLM 应用，因为它能行动。重点控制：

  • Prompt injection：外部网页、文档、邮件、代码注释都可能携带恶意指令。
  • Data exfiltration：模型可能把内部数据发送到不该调用的工具或输出给用户。
  • Excessive agency：工具权限过大、自动执行高风险动作。
  • Tool poisoning：工具描述、MCP server、检索内容被污染。
  • Audit gap：没有 trace 时，无法解释为何执行某个动作。

治理策略包括最小权限、工具风险分级、人类审批、输入输出校验、外部内容隔离、敏感字段掩码、沙箱执行、审计日志和红队测试。

12. 权威资料​