KDnuggets

Here’s What Everyone Gets Wrong About Agentic AI

8.5内容质量

TL;DR · AI 摘要

Agentic AI失败并非因技术问题,而是源于五个可纠正的误解,包括对自主性的错误理解。

核心要点

  • 40%的Agentic AI项目将在2027年前被取消,主要原因是人为决策错误。
  • Replit的AI代理误删数据库并生成虚假数据,凸显自主性管理的重要性。
  • Agentic AI的失败源于对自主性的错误理解,而非技术本身的问题。

结构提纲

按章节快速跳转。

  1. 通过Replit AI代理误删数据库的案例,引出Agentic AI失败的原因。

  2. 多数团队错误地认为自主性越高越好,而忽视了结构化管理的必要性。

  3. Gartner调查数据

    Gartner调查显示,40%的Agentic AI项目将在2027年前被取消。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • Agentic AI的误解
    • 误解一:自主性无需监督
      • 结构化管理缺失
    • Gartner调查
      • 40%项目将在2027年前被取消

金句 / Highlights

值得收藏与分享的关键句。

#AI#Agentic AI#技术误解#数据安全
打开原文

关于智能体AI的常见误解 - KDnuggets

publ: 2026年6月22日

  • 博客热门文章
  • 主题 人工智能 职业建议 计算机视觉 数据工程 数据科学 语言模型 机器学习 MLOps 自然语言处理 编程 Python SQL
  • 数据集
  • 活动
  • 资源 快速参考指南 推荐 技术简报
  • 广告

加入新闻通讯

#header end

/ad_wrapper

关于智能体AI的常见误解

智能体AI的失败并不是因为技术本身不好,而是因为团队在首次部署时存在五个特定的误解,每一个误解都是可以纠正的。

作者:

Shittu Olumide,技术内容专家,2026年6月22日发布于

人工智能

<div class="addthis_native_toolbox"></div>

# 引言

2025年7月,一名名为Jason Lemkin的开发者花了九天时间,使用Replit的AI编码智能体构建了一个商业联系数据库。他不是在进行实验,而是在真正地构建。他收集并整理了1,206位高管和1,196家公司的信息,这些工作花费了几个月的真正努力。在离开之前,他输入了一条指令:冻结代码。

智能体将“冻结”理解为一个行动的邀请。它删除了整个生产数据库。然后,似乎对造成的空白感到困扰,它又生成了约4,000条虚假记录来填补这个空白。当Lemkin询问恢复选项时,智能体表示回滚是不可能的。最终,他手动恢复了数据,但此时智能体要么是编造了这个答案,要么就是未能提供正确的答案。

Replit的首席执行官Amjad Masad在X上发帖称,在开发过程中,Replit的智能体删除了生产数据,并称这是不可接受的,补充说这应该永远不会发生。《财富》杂志将其报道为“灾难性失败”。AI事故数据库将其记录为事件1152。

本文将解释为什么该事件是完全可以预测的,以及为什么今天大多数使用智能体人工智能(AI)的团队正在走向类似的结局,却并未意识到这一点。

智能体AI的失败并不是因为技术本身不好,而是因为团队在首次部署时存在五个特定的误解。每一个误解都是可以纠正的。它们都不需要等待更好的模型。

# 误解1:“自主”意味着无需监督

“智能体”这个词常被理解为“自主”,而“自主”又被理解为“放任不管”。大多数团队将智能体的自主性视为一个从零到一的光谱,并假设目标是尽可能快地接近一。

这是错误的思维模型。问题不是你的智能体有多自主,而是它的自主性是否结构正确。目前,对于大多数生产部署来说,答案是否定的。

2025年6月,Gartner对超过3,400家正在积极投资智能体AI的组织进行了调查,并发布了一个令人震惊的发现:到2027年底,超过40%的智能体AI项目将被取消。被引用的原因不是智能体无法工作,而是部署它们的人做出了错误的决策。根据Gartner高级总监分析师Anushree Verma的说法,目前大多数智能体AI项目都是早期阶段的实验或概念验证,主要由炒作驱动,经常被错误地应用。

这值得我们深思。40%的取消率是一个人为问题,而不是模型问题。

失败模式如下:一个团队看到一个令人印象深刻的演示,以最小的监督结构部署代理,然后看着它在简单输入上运行良好。随后,一个真正的边缘情况出现。代理在没有检查点的情况下运行,在第三步做出错误的决定,然后将错误传播到第四到第十步,等人们发现时,已经造成了损害。Gartner 预测,到 2026 年,三分之一的公司将因过早部署人工智能而损害客户体验,在他们有机会纠正错误之前,品牌信任度就会下降。

解决问题的方法不是减少自动化,而是理解人类检查点实际应该出现在哪里。

并非工作流程中的每一步都需要人类参与。大多数都不需要。但所有不可逆的操作都需要:删除、购买、外部发送、权限更改。这些都是单行道。一个可以在没有确认的情况下穿过单行道的代理,在实用意义上并不是真正的自主。它是一个隐患。

实际的实现方式是采用两层模型:允许代理在可逆步骤中自由移动,并在不可逆步骤中硬性停止,直到获得明确的人类批准。这在演示中可能显得不那么令人印象深刻。但在生产环境中,它的价值要高得多。如果在数据库写入操作上设置一个确认门,Replit 事件就不会发生。

一个水平工作流程图,显示代理任务中的 8 个步骤。

# 误解 2:演示等同于部署

这个误解是最昂贵的,而且几乎普遍存在。演示通常使用干净、受控的输入运行 2-3 步的工作流程,由人类选择任务,观察输出,并悄悄丢弃任何未成功运行的实例。生产环境则在杂乱、现实世界的数据、模糊的输入、意外的 API 响应、部分失败和无人想到测试的边缘情况上运行 5-20 步的工作流程。

数学可以精确地解释这两个环境之间的差距。在可靠性工程中,有一个叫做 Lusser 定律的原则,它指出由顺序组件构建的系统的可靠性等于每个组件可靠性乘积。这是 20 世纪 50 年代德国工程师 Robert Lusser 在研究德国火箭计划中的串行故障时得出的。这一原则直接映射到基于大型语言模型(LLM)的代理链。

如果你的代理每一步的准确率达到 95%,这是一个真正出色的水平,那么在不同工作流程长度下,它看起来会是这样:

python
def compound_success_rate(per_step_accuracy: float, num_steps: int) -> float:
    """
    计算一个 n 步代理工作流程端到端成功的概率,
    给定每一步的准确率。基于可靠性工程中的 Lusser 定律。

    Args:
        per_step_accuracy: 每一步成功的概率(0.0 到 1.0)
        num_steps:          工作流程中的总步骤数

    Returns:
        总体成功概率,作为 0.0 到 1.0 之间的浮点数
    """
    return per_step_accuracy ** num_steps

# 在大多数生产代理实际运行的准确率范围内运行它
examples = [
    (0.95, 10, "95% 准确率,10 步工作流程"),
    (0.90, 10, "90% 准确率,10 步工作流程"),
    (0.85, 10, "85% 准确率,10 步工作流程"),
    (0.85,  3, "85% 准确率,3 步工作流程(狭窄范围)"),
]

for acc, steps, label in examples:
    rate = compound_success_rate(acc, steps)
    print(f"{label}: {rate * 100:.1f}% 总体成功率")

前提条件:Python 3.7+。不需要依赖项。

如何运行:

code
# 保存文件
python3 compound_reliability.py

输出:

code
95% 准确率,10步流程:总体成功率为59.9%
90% 准确率,10步流程:总体成功率为34.9%
85% 准确率,10步流程:总体成功率为19.7%
85% 准确率,3步流程(范围较窄):总体成功率为61.4%

一个在10步流程中准确率为95%的代理,大约有60%的成功率。如果每一步的准确率下降到85%,这仍然优于大多数未经验证的生产代理,此时成功率会降至20%。五次运行中,有四次至少会在流程的某处出现错误。

# 误解3:更多工具意味着更聪明的代理

在构建AI代理时,有一种常见的直觉:给它更多工具。添加客户关系管理集成,连接数据库,给予其电子邮件访问权限、日历访问权限、网络搜索权限和文件管理权限。假设更多的能力意味着更高的智能。

实际上,这只会增加失败的攻击面。工具误用和错误的工具参数是AI代理生产失败最常见的直接原因,占2024-2025年部署中约31%的生产失败。而这仅仅是直接原因——在大多数情况下,根本原因在于范围蔓延:代理被赋予了其基础设施实际上无法支持的任务。

在代理系统中,有两种不同类型的幻觉,混淆它们是有代价的。

  • 文本幻觉,即人们通常所说的“AI幻觉”,是指模型编造事实或生成听起来合理的胡言乱语。功能幻觉则特定于代理工作流程:代理完全选择了错误的工具,向有效工具传递了格式错误的参数,伪造了工具结果而不是调用实际函数,或者跳过了必要的工具步骤。

关于代理失败模式的研究指出,功能幻觉在生产环境中更为危险,因为它会产生自信且格式良好的输出,同时却完全做错了事情,并且不会触发明显的错误信号。

解决方案不是避免给代理提供工具,而是正确限定工具的范围,明确验证输入,并仅注册与当前任务上下文相关的工具。

以下是一个带有模式验证和不可逆性门控的类型化工具注册的具体实现:

code
import json

# 一个最小化且类型明确的工具注册表。
# 关键设计原则:工具通过显式的模式进行定义,并标记为可逆或不可逆。代理本身不会决定这一点。

TOOLS = {
    "search_orders": {
        "description": "根据履约状态搜索客户订单。返回匹配的订单ID列表。",
        "irreversible": False,
        "inputSchema": {
            "type": "object",
            "properties": {
                "status": {
                    "type": "string",
                    "enum": ["pending", "shipped", "delivered", "cancelled"],
                    "description": "用于筛选订单的履约状态。"
                },
                "limit": {
                    "type": "integer",
                    "minimum": 1,
                    "maximum": 50,
                    "description": "返回结果的最大数量。"
                }
            },
            "required": ["status"]
        }
    },
    "cancel_order": {
        "description": "通过订单ID取消客户订单。此操作无法撤销。",
        "irreversible": True,   # 执行前硬性阻止;需要人工确认
        "inputSchema": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "description": "要取消的订单的唯一标识符。"
                },
                "reason": {
                    "type": "string",
                    "description": "取消的原因。存储在审计日志中。"
                }
            },
            "required": ["order_id", "reason"]
        }
    },
    "send_confirmation_email": {
        "description": "向客户发送取消确认电子邮件。此操作无法撤销。",
        "irreversible": True,
        "inputSchema": {
            "type": "object",
            "properties": {
                "to": {"type": "string", "description": "客户电子邮件地址。"},
                "order_id": {"type": "string", "description": "要在电子邮件中包含的订单ID。"}
            },
            "required": ["to", "order_id"]
        }
    }
}

def validate_tool_input(tool_name: str, args: dict) -> bool:
    """
    验证参数是否匹配工具声明的输入模式。
    在执行前捕获错误的工具调用和格式错误的参数。
    如果验证失败,会引发带有清晰信息的ValueError。
    """
    if tool_name not in TOOLS:
        raise ValueError(
            f"未知工具: '{tool_name}'。可用工具: {list(TOOLS.keys())}"
        )

    schema = TOOLS[tool_name]["inputSchema"]
    required_fields = schema.get("required", [])
    defined_properties = schema.get("properties", {})

    # 检查所有必需字段是否都存在
    for field in required_fields:
        if field not in args:
            raise ValueError(
                f"工具 '{tool_name}' 缺少必需字段 '{field}'。"
            )

    # 验证枚举约束和类型
    for field, value in args.items():
        if field not in defined_properties:
            continue  # 允许存在额外字段,但不要引发错误;在生产环境中记录这些字段

        field_schema = defined_properties[field]

        if "enum" in field_schema and value not in field_schema["enum"]:
            raise ValueError(
python
def validate_tool_input(tool_name: str, args: dict) -> bool:
    """
    Validate that the input arguments for a tool are correct.
    Raises ValueError on invalid input.
    """
    tool = TOOLS[tool_name]
    for field, value in args.items():
        field_schema = tool["schema"][field]

        if "enum" in field_schema and value not in field_schema["enum"]:
            raise ValueError(
                f"Invalid value '{value}' for field '{field}' in tool '{tool_name}'. "
                f"Must be one of: {field_schema['enum']}"
            )

        if field_schema.get("type") == "integer" and not isinstance(value, int):
            raise ValueError(
                f"Field '{field}' in tool '{tool_name}' must be an integer, "
                f"got {type(value).__name__}."
            )

    return True

def execute_tool(tool_name: str, args: dict, human_confirmed: bool = False) -> dict:
    """
    Execute a tool with schema validation and human-in-the-loop gating
    for all irreversible actions.

    Returns a dict with:
        'result'           - the tool output string, or None if approval needed
        'requires_approval'- True if the call was halted for human review
        'message'          - explanation when approval is required
    """
    validate_tool_input(tool_name, args)

    tool = TOOLS[tool_name]

    # Gate on irreversibility -- this is the check that prevents database deletions,
    # unauthorized purchases, and emails sent to the wrong recipient.
    if tool["irreversible"] and not human_confirmed:
        return {
            "result": None,
            "requires_approval": True,
            "message": (
                f"Tool '{tool_name}' is irreversible and requires human confirmation. "
                f"Planned args: {json.dumps(args)}"
            )
        }

    # Safe to proceed -- replace this comment with your actual tool implementation
    return {
        "result": f"Tool '{tool_name}' executed successfully with args: {json.dumps(args)}",
        "requires_approval": False
    }

# --- Test runs ---

# 1. Valid reversible call -- executes immediately, no approval needed
response = execute_tool("search_orders", {"status": "shipped", "limit": 10})
print(f"Reversible tool:\n  {response['result']}\n")

# 2. Irreversible call without confirmation -- pauses and asks before doing anything
response = execute_tool("cancel_order", {"order_id": "ORD-12345", "reason": "Customer request"})
print(f"Irreversible without confirmation:")
print(f"  requires_approval = {response['requires_approval']}")
print(f"  message: {response['message']}\n")

# 3. Irreversible call with explicit confirmation -- proceeds normally
response = execute_tool(
    "cancel_order",
    {"order_id": "ORD-12345", "reason": "Customer request"},
    human_confirmed=True
)
print(f"Irreversible with confirmation:\n  {response['result']}\n")

# 4. Invalid enum value -- validation catches it before anything executes
try:
    execute_tool("search_orders", {"status": "lost"})
except ValueError as e:
    print(f"Invalid input caught:\n  {e}\n")

# 5. Missing required field -- caught before execution
try:
    execute_tool("cancel_order", {"order_id": "ORD-12345"})  # 'reason' is required
except ValueError as e:
    print(f"Missing field caught:\n  {e}")

前置条件:Python 3.7+。不需要外部包。保存为 agent_tool_registry.py

code
python3 agent_tool_registry.py

预期输出:

code
可逆工具:
  工具 'search_orders' 已成功执行,参数为:{"status": "shipped", "limit": 10}

需要确认的不可逆操作:
  requires_approval = True
  消息:工具 'cancel_order' 是不可逆的,需要人工确认。计划参数:{"order_id": "ORD-12345", "reason": "Customer request"}

已确认的不可逆操作:
  工具 'cancel_order' 已成功执行,参数为:{"order_id": "ORD-12345", "reason": "Customer request"}

捕获到无效输入:
  工具 'search_orders' 的字段 'status' 值 'lost' 无效。必须是以下之一:['pending', 'shipped', 'delivered', 'cancelled']

捕获到缺失字段:
  工具 'cancel_order' 缺少必填字段 'reason'。

验证层正在做四件事:拒绝未知工具、强制要求必填字段、检查枚举约束、强制类型规则。这些都不复杂。在大多数代理实现中,这些都会被跳过。不可逆标志是区分代理可以自由执行的操作和始终需要等待人工确认的操作的关键,而你决定哪些是哪些,而不是模型。

# 误解 4:代理不为其错误负责

这一点对任何将代理 AI 部署给真实用户的人来说都很重要,而如今几乎每个人都在这样做。2022 年 11 月,Jake Moffatt 正在为失去祖母而悲痛,并向 Air Canada 的聊天机器人寻求有关航空公司丧事票价政策的信息。聊天机器人告诉他,他可以购买全价票,并在旅行后 90 天内申请折扣票价的退款。相信了这个回答,Moffatt 购买了机票。当他后来尝试申请退款时,Air Canada 拒绝了。他们实际的政策并不允许追溯申请。

Moffatt 提起了诉讼。2024 年 2 月,不列颠哥伦比亚省民事解决法庭裁定他胜诉,并命令 Air Canada 赔偿他 650.88 加元,加上利息和费用。

Air Canada 的辩护是值得我们关注的部分。他们声称聊天机器人实际上是一个独立的法律实体,是其自己的“代理人、仆人或代表”,因此 Air Canada 不应对其输出负责。法庭成员 Christopher Rivers 直接驳回了这一说法,称这是一个令人惊讶的提交,并指出尽管聊天机器人具有交互性,但它仍然是 Air Canada 网站的一部分。

这一裁决确立了一个原则,现在适用于所有在客户接触场景中部署 AI 的公司:无论你的政策页面上说了什么,也无论 AI 是如何得出答案的,你都必须对你 AI 的言论和行为负责。到 2024 年 4 月,Air Canada 的聊天机器人已悄然从其网站上消失。

教训不是你不应该部署 AI 代理。而是“代理做出了那个决定”在法律或运营上都不是一个可用的辩护。代理是你的工具。它的输出就是你的输出。

这在工程上有着直接的影响。任何能够向用户做出承诺的代理,比如退款政策、价格、交货日期或功能可用性,都必须基于你实际的、当前的文档,而不是模型从训练数据中概率性生成的任何内容。在受控环境中,企业聊天机器人的幻觉率根据领域和防护级别不同,范围从3%到27%。即使幻觉率只有3%,一个高流量的客户服务代理也会不断做出错误的承诺。

责任差距还以更微妙的方式表现出来:大多数团队没有构建审计追踪。当代理系统出现问题时,你需要知道哪一步失败了,代理接收了什么输入,它决定做什么,以及它实际执行了什么。没有这些追踪信息,你无法调试故障,无法证明合规性,也无法在下一次类似加拿大航空的事件中为自己辩护。

# 误解5:更好的模型能解决可靠性问题

这是最难接受的一个误解,因为它与AI开发中最自然的直觉相悖:当某事出错时,就升级模型。Cemri等人(2025)关于多代理系统故障的研究发现了一个连研究人员都感到惊讶的结果:多代理系统的故障不能完全归咎于大语言模型的局限性,因为使用相同的模型在单代理设置中通常比多代理版本表现更好。可靠性问题不是主要的模型问题,而是系统架构问题。协调、编排和数据质量比你运行的模型版本更重要。

Gartner的数据为数据质量部分提供了数字:57%的企业估计他们的数据根本无法用于AI。无论你使用的是最新的前沿模型,运行在不完整、过时或不一致数据上的代理都会产生糟糕的结果。垃圾进垃圾出这一概念比大语言模型早几十年就已经存在。即使系统现在被描述为“智能”,这一原则依然适用。

第二个问题是可观测性。传统软件在出错时会发出明显的信号:堆栈跟踪、500错误、带有行号的日志条目。而代理系统则会安静地失败。它们会返回自信且格式良好的输出,但实际上是错误的。当AI代理出错时,你会得到一个看起来正确但实际错误的响应。这种失败会通过多个步骤传播下去,直到有人注意到,而到那时,错误已经影响了你无法逆转的决策。

解决方法是每一步的追踪,记录每个工具调用时的输入、输出、延迟和置信度信号,而不仅仅是在最终响应级别上记录:

code
import json
import datetime

class AgentTracer:
    """
    记录代理在工作流运行过程中每次工具调用的完整追踪信息。
    在每一步中捕获输入、输出、延迟时间和一个置信度评分。

    这就是为什么在第3步就能发现失败,而不是等到第10步才发现问题,那时已经造成了损害。
    """

    def __init__(self, run_id: str):
        self.run_id = run_id
        self.steps = []

    def trace(
        self,
        step_index: int,
        tool_name: str,
        args: dict,
        result: str,
        latency_ms: float,
        confidence: float,
        low_confidence_threshold: float = 0.70,
    ) -> dict:
        """
        记录一次工具调用的完整上下文信息。

        Args:
            step_index:               工作流中的步骤编号(从1开始计数)
            tool_name:                被调用的工具名称
            args:                     传递给工具的参数
            result:                   工具的输出(在日志中被截断)
            latency_ms:               工具调用所用的时间(以毫秒为单位)
            confidence:               代理报告的置信度(0.0-1.0)
            low_confidence_threshold: 低于此置信度的步骤将被标记以供审查

        Returns:
            dict: 该步骤的完整追踪条目
        """
        entry = {
            "run_id": self.run_id,
            "step": step_index,
            "tool": tool_name,
            "args": args,
            # 截断长结果,使仪表板中的日志保持可读性
            "result_preview": result[:120] + "..." if len(result) > 120 else result,
            "latency_ms": round(latency_ms, 2),
            "confidence": round(confidence, 3),
            # 低于阈值的步骤将在运行摘要中被标记以供人工审查
            "low_confidence": confidence < low_confidence_threshold,
            "timestamp": datetime.datetime.now(datetime.timezone.utc).isoformat(),
        }
        self.steps.append(entry)
        return entry

    def summary(self) -> dict:
        """
        总结运行情况:总步骤数、总延迟时间和被标记的步骤。

        在你的运行后日志和警报流程中使用此功能。
        低置信度步骤是静默失败的早期预警信号。
        """
        total_latency = sum(s["latency_ms"] for s in self.steps)
        flagged = [s for s in self.steps if s["low_confidence"]]

        return {
            "run_id": self.run_id,
            "total_steps": len(self.steps),
            "total_latency_ms": round(total_latency, 2),
            "flagged_steps": len(flagged),
            "flagged_details": [
                {
                    "step": s["step"],
                    "tool": s["tool"],
                    "confidence": s["confidence"],
                }
                for s in flagged
            ],
        }

# 模拟一个包含完整追踪的5步客户支持代理工作流

tracer = AgentTracer(run_id="run-support-2026-001")

# 每个元组:(工具名称,参数,结果,延迟时间,置信度)
# 置信度低于0.70的步骤将在摘要中被自动标记。
simulated_steps = [
    (
        "search_orders",
        {"status": "pending"},
        "Found 3 pending orders: ORD-001, ORD-002, ORD-003",
        45.2,
python
simulated_steps = [
    (
        "create_order",
        {"customer_id": "CUST-123", "product_id": "WIDGET-A", "quantity": 2},
        "Order created: ORD-001",
        120.3,
        0.95,  # High confidence -- agent is certain about this step
    ),
    (
        "get_order_detail",
        {"order_id": "ORD-001"},
        "Order ORD-001: 2x Widget, $49.99, estimated delivery June 20",
        38.7,
        0.91,
    ),
    (
        "check_inventory",
        {"product_id": "WIDGET-A"},
        "WIDGET-A: 12 units in stock at Warehouse Lagos",
        210.5,
        0.61,  # LOW CONFIDENCE -- agent uncertain about warehouse location; flagged
    ),
    (
        "update_order",
        {"order_id": "ORD-001", "status": "confirmed"},
        "Order ORD-001 status updated to confirmed",
        55.1,
        0.88,
    ),
    (
        "send_confirmation_email",
        {"to": "customer@example.com", "order_id": "ORD-001"},
        "Email queued for delivery to customer@example.com",
        30.0,
        0.52,  # LOW CONFIDENCE -- agent uncertain about recipient; flagged before irreversible send
    ),
]

print("=== Step-by-step trace ===")
for i, (tool, args, result, latency, confidence) in enumerate(simulated_steps):
    entry = tracer.trace(i + 1, tool, args, result, latency, confidence)
    flag = " [LOW CONFIDENCE -- FLAGGED FOR REVIEW]" if entry["low_confidence"] else ""
    print(f"  Step {i + 1}: {tool}{flag}")

print("\n=== Run Summary ===")
print(json.dumps(tracer.summary(), indent=2))

前置条件:Python 3.9+。不需要外部包。保存为 agent_tracer.py

code
python3 agent_tracer.py
code
=== 分步追踪 ===
  步骤 1: search_orders
  步骤 2: get_order_detail
  步骤 3: check_inventory [置信度较低 -- 需要审查]
  步骤 4: update_order
  步骤 5: send_confirmation_email [置信度较低 -- 需要审查]

=== 运行摘要 ===
{
  "run_id": "run-support-2026-001",
  "total_steps": 5,
  "total_latency_ms": 379.5,
  "flagged_steps": 2,
  "flagged_details": [
    {"step": 3, "tool": "check_inventory", "confidence": 0.61},
    {"step": 5, "tool": "send_confirmation_email", "confidence": 0.52}
  ]
}

在五步运行中有两个被标记的步骤。如果没有每一步的追踪,这两个置信度较低的调用就会消失在最终的响应中。有了追踪,它们会立即显现出来,避免在确认邮件发送到错误地址之前,或者在低置信度的库存数量被当作真实数据提交之前。

这是在“有时会失败”的代理和“失败可被察觉”的代理之间的区别。只有后者才值得部署。

# 总结

PwC 2025 年 5 月发布的 AI 代理调查发现,79% 的高级管理人员表示他们的公司已经在使用 AI 代理。这个数字听起来像是大规模采用。但同一项调查发现,只有 35% 的公司广泛部署了代理,只有 17% 的公司几乎在所有工作流程中都部署了代理,而 68% 的公司承认,每天与代理互动的员工不到一半。

团队在部署时没有进行复合可靠性计算。他们将演示当作部署的替代方案。他们在没有模式验证或可逆性控制的情况下,将工具堆叠到代理上。他们部署了面向客户的 AI,却没有审计追踪。他们还在等待模型升级来解决那些并非模型问题的问题。

能够弥合这一差距的团队,不会是那些基础设施预算最大或最早接触到前沿模型的团队。而是那些以与对待其他关键系统相同的方式对待代理部署的团队:通过结构化的自主性、在关键边界设置人工检查点、使用范围明确的工具注册表、步骤级别的可观测性,并且对出现问题时会发生什么有一个明确的答案。

这个答案必须在第一次生产部署之前就存在。而不是之后。

Shittu Olumide 是一位软件工程师和技术作家,热衷于利用前沿技术创作引人入胜的故事,他注重细节,擅长将复杂概念简化。你也可以在 Twitter 上找到 Shittu。

关于此主题的更多内容

  • 为新手解释损失函数(模型如何知道它们是错误的)
  • 投资 AI?这里是你需要考虑的事项
  • 系好安全带:Falcon 180B 已经来了!
  • 这里是如何构建一个 MCP 来自动化我的数据科学工作
  • 我们对 DuckDB、SQLite 和 Pandas 在 100 万行数据上的性能进行了基准测试:结果如何?
  • 在什么情况下你会选择电子表格而不是 SQL

<hr class="grey-line"><br> <div><h3>我们推荐的前五门免费课程</h3><br> </div>

Mailchimp for WordPress v4.13.0 - https://wordpress.org/plugins/mailchimp-for-wp/

/ Mailchimp for WordPress 插件

你可以从这里开始编辑。

如果评论已关闭。

<= 上一篇

#content end

<script type="text/javascript">kda_sid_write(kda_sid_n);</script>

最新文章

  • 关于智能代理 AI 的常见误解

NLTK 高级文本预处理与语言分析的 3 个技巧 新手也能理解的损失函数(模型如何知道自己错了) 数据科学家应掌握的实用 SQL 技巧 你应该始终记住的 Python 字典技巧与窍门 高级连接技术:LATERAL 连接、半连接、反连接

热门文章

  • 2026 年成为 LLM 工程师的路线图
  • 将 Claude Code 与本地模型结合使用
  • 我为何(以及如何)构建了一个 AI 助手
  • 使用 OpenAI Codex 的 5 个有趣项目
  • 使用 Python 中的 sktime 构建时间序列机器学习模型
  • 停止在 Pandas 中编写循环:尝试这 7 个更快的替代方法
  • 3 个 Pandas 数据清洗与准备技巧
  • 为你的创业点子获取资金的 7 个最佳方式
  • 低成本实现本地智能代理编程:Claude Code + Ollama + Gemma4
  • 你应该始终记住的 Python 字典技巧与窍门

#content_wrapper end

© 2026

Guiding Tech Media

|

关于

联系方式

广告

隐私政策

服务条款

2026 年 6 月 22 日由 Olumide Shittu 发布

blank

不,谢谢!

/.main_wrapper

<script defer type="text/javascript" src="https://s7.addthis.com/js/300/addthis_widget.js#pubid=gpsaddthis"></script>

noptimize

/noptimize