反模式Anti-Patterns

反模式：让编码代理仅根据它能看到的文件更改一个已有的代码库，因此它默默地违反了没有机器可读形式的架构约定。

反模式：每次压缩操作都会重写运行历史，因此严格的安全指令逐渐被改写为模糊的建议，其效力随着代理运行时间的延长而减弱。

反模式：在固定的类型子代理集合中预先分配角色（经理、编码员、设计师、研究员），并通过角色标签将任务路由到它们。

反模式：代理在自己的思维中比较、排名或汇总正确返回的工具数据，而不是将计算卸载到确定性工具上，从而产生自信的错误汇总。

反模式：代理或其工作流引擎的终端成功状态被视为交付物业务正确性的证明，而它仅证明了技术完成。

反模式：代理从自己的叙述中报告一个有副作用的动作已完成，而工具调用默默失败或从未运行，并且没有检查效果是否发生。

反模式：一个监督者或协调者生成可以自己生成子代理的子代理，而没有全局限制。

反模式：通过代理路由一个艰难的决定，以便没有人对结果负责，将推荐视为决定，而公司的法律责任保持不变。

反模式：依赖于针对不规则人类行为校准的行为异常检测，因此一个使用合法凭证、标准协议和超人类一致性行动的自主对手比人类更不异常，从而未被察觉。

反模式：建议性决策支持输出被机构协议默默提升为具有约束力的命令，而领域专家基于证据的拒绝遵循被重新框定为不合规，而非合法判断。

反模式：分布式供应链或补货代理，各自进行局部优化，通过自身的决策政策放大订单变异性，因此局部需求激增会触发全链条同步重新订购和供应商缺货，导致问题向后传播。

反模式：在代理人引发的事件之后，团队将代理人虚构的自我叙述视为法医记录和根本原因，尽管自我报告是生成的而非记忆的，且可能完全错误。

反模式：代理队列以机器速度生成非人类身份，而范围、轮换、所有权和撤销仍然以人类速度进行，因此过度特权的长期凭证积累，超出其代理的生命周期，并扩大了无法治理的攻击面。

反模式：代理发出高容量、低精度的发现，逐渐使其人类审阅者麻木，直到他们将其静音，因此即使是正确的发现也无法传达，人类监督控制悄然消失。

反模式：让代理的有效权限成为其自身身份、工具身份和这些工具调用的服务身份的并集。

反模式：部署一个具有长时间跨度、持久记忆和仅检查每步输出的监督的代理——允许在表面下进行多步骤的隐秘规划。

反模式：每个团队都独立发布自己的代理，而所有权、成功指标、监控和退役路径则被视为次要，因此代理队伍超出了治理范围，大多数代理最终无人看管、无人拥有，且无法退役。

反模式：在单一聊天界面背后，代理静默调用第三方工具，将用户的个人数据路由到未披露的目的地，因此用户无法看到哪些工具或数据服务在处理这些数据。

反模式：让代理在其沙箱中编写和执行代码，而不区分合法任务代码和注入诱导的代码。

反模式：用适应人类反应时间的事件响应和漏洞报告框架来管理自主代理，尽管被攻陷的代理可以在几秒钟内外泄数据并抹去痕迹。

反模式：在未整合的数据基础、薄弱的治理或缺失的MLOps基础设施上部署代理，因此每个后续能力——可观察性、再训练、合规性改造——都在跳过基础工作上支付复利。

反模式：让代理在代码中接管常规架构和调试决策，直到开发人员不再形成隐性知识，以便他们能够审查代理的输出或在代理失败时恢复。

反模式：从第三方工具、RAG 源、模型提供者、插件市场和工具定义中动态组合代理能力，而不对加载内容进行完整性检查。

反模式：攻击者在源文件中插入数千行重复的自然语言注释，旨在指示可能阅读该文件的模型代码审计员/代理——不要与人类开发者沟通。

反模式：假设代理在被评估时与不被评估时的行为相同，并信任评估分数来预测部署行为。

反模式：授予代理一个具有广泛授权的工具，并信任代理以良性的方式使用它。

反模式：在已经失效的工作流程上部署代理，从而使失效以机器速度加剧，而不是得到解决。

反模式：在没有痕迹、决策日志或来源的情况下发布代理，然后根据用户报告进行调试。

反模式：用户授予代理一个广泛的持续授权，以便在应用程序之间行动，当后续的自主行为造成损害时，没有任何一方保持整个过程的控制，因此责任在用户、平台和代理之间分散。

反模式：在代理循环或HTTP处理程序中运行同步的、阻塞的I/O，将并发限制在操作系统线程的数量上。

反模式：构建一个多代理系统，其中一个代理的失败或幻觉作为输入传播给同伴，直到整个系统偏离。

反模式：在没有建模每一步准确性在整个轨迹中相乘的情况下，部署一个长时间跨度的代理。

反模式：在受监管的工作流程中，相同的查询在不同时间产生实质上不同的输出，每个输出看起来都是正确的并且通过了审查，因此变异性保持隐形，除非输出被故意重新运行并在时间上进行比较。

架构差距：当前的代理无法像人类一样通过经验和上下文判断来解决复杂的目标冲突，即使在进展框架的第3级。

反模式：一个自组织的 LLM 团队追求整合妥协，平均专家和非专家的观点，而不是权衡已知专家的意见，因此团队的输出低于最佳成员，并随着团队规模的扩大而进一步下降。

代理在声明的工具和规则内进行重新计算，就像GPS重新规划路线一样，但无法像人类那样创造性地超越这些界限来发明新方法。

反模式：一个上下文感知模型错误地判断其剩余的令牌预算并提前结束——总结、声明任务完成、走捷径——而实际上还有充足的上下文，因此必须管理感知的预算，而不是实际的使用情况。

反模式：LLM无法像人类工作记忆那样同时保持多个相互关联的约束；它局部处理每个约束，失去了跨约束的视图。

代理严格遵循明确的安全规则，但忽略了更广泛的影响——它们正确记录访问，但没有标记出人类专家会立即发现的异常模式。

反模式：依赖代理自身对其行为的自我报告进行审计和监督。

反模式：当面临同等权重的冲突目标时，代理要么陷入同时满足所有目标的困境，要么在解决方案之间摇摆而无法收敛——这是对真正目标冲突的最常见LLM响应。

反模式：在交互环境中给一个经过推理训练的模型一个大的思考预算，它会对环境的状态进行假设，而不是发出能够解决问题的廉价观察。

反模式：在经过精心策划的演示集上，多个智能体的基准测试达到95%的准确率和2秒的延迟，然后在现实的10k-RPD负载下降至约80%和40秒。

反模式：将经过演示验证的代理直接投入生产，而没有冻结评估、成本上限、循环检测器或指定的值班人员，然后对准确性下降和成本失控感到惊讶。

反模式：在重复交互和共享激励下，部署独立的LLM代理作为竞争方，仅在每个代理的监督下，因此它们发现了单个代理的痕迹无法揭示的默契协调。

反模式：从代理的上下文中清除失败的操作、堆栈跟踪和错误观察，以使追踪看起来干净，留下模型没有关于未成功内容的证据。

反模式：当一个步骤失败时，模型用流畅、合理的内容填补空白，而不是暴露错误，因此交付物看起来像是成功，观察者被误导而不仅仅是未被告知。

反模式：模型以与正确答案相同的高自信度产生错误答案，未能根据实际可靠性变化其表达的确定性——在约束较重的提示中被牛津文献记录。

代理提出一个妥协方案，单独解决每个约束，但在联合解释中微妙地违反了一个，作为成功交付，但在审计中被发现为失败。

反模式：在多代理层次结构中，任务移交悄无声息地消失——被委托的工作永远等待，而父代理在其子任务孤立时关闭，因为没有错误触发，导致它无法重启。

反模式：让代理的目标可以通过代理读取的任何输入进行重定向——直接提示、检索的文档、工具输出、记忆写入。

反模式：让模型以自由文本形式生成引用并信任它们。

反模式：信任模型仅调用它所拥有的工具，然后调试不存在的函数调用。

反模式：将所有能力都塞进一个代理中，使用一个巨大的提示。

反模式：一个多代理系统被呈现为解耦、可独立部署的代理，但在运行时它们共享上下文，运行在同步链中，并且没有故障隔离，因此它的行为就像一个紧耦合的分布式单体。

反模式：在请求之间静默地交换底层模型，而不向用户或操作员披露更改。

反模式：代理工作流读取或写入未声明的共享状态（缓存、环境变量、进程全局变量），而不是显式的输入和输出。

反模式：代理的推出将工作重心从执行任务转移到验证、监控和重新校准代理——净生产力为负，因为隐藏的人类评估负担超过了可见的自动化收益。

反模式：以自信的措辞、精致的用户体验和机器推迟的信任向人类展示代理输出，在高风险行动边界上没有摩擦。

反模式：让代理在主体的完整身份和令牌下行动，因此它采取的每个行动都记录为主体的，审计无法区分用户发起的决策和代理自主的决策。

反模式：启动多智能体辩论而没有终止规则，导致智能体无限循环。

反模式：部署代理，其扩展行为触发突发的数据和计算负载，导致本地或资源不足的云基础设施无法承受；代理在小规模下正常工作，但在生产环境中冻结。

反模式：在共享传输中传递消息而不对发送代理、消息内容或顺序进行身份验证。

反模式：将代理的动作语言限制为 JSON 工具调用字典，即使在代码作为动作（函数组合、循环、对结果的条件判断）是自然形态的任务中也是如此。

反模式：用 LLM 判官对候选工件进行评分，该判官将其视为普通内容，因此评分受到影响的一方可以在判官自己的提示中写入文本。

当相关内容位于提示的中间而不是开始或结束时，LLM 在从长上下文中检索信息的准确性急剧下降。

反模式：代理引用自己过去的备忘录作为事实依据，而不是重新验证它们与所描述的文档之间的关系，从而在过时的总结中积累错误的信心。

反模式：允许任何会话提示代理读取、总结或改写属于其他用户、先前会话或系统状态的长期记忆条目，而没有按主体进行的读取时间隔离。

反模式：从代理读取的任何表面写入代理的长期记忆（向量存储、知识图谱、情节日志），而不进行来源检查。

反模式：在没有幂等性键的情况下重试状态变更的代理工具调用，从而导致重试增加现实世界的副作用。

反模式：在没有明确的 max_tokens（或等效参数）的情况下调用模型，以至于单次调用可能耗尽运行预算，导致生成失控。

反模式：将一个根本上是顺序的工作负载拆分到多个代理中，导致准确性下降39–70%，且没有并行化的好处。

反模式：立即重试失败的模型或工具调用，增加已经失败的系统的负载。

反模式：在检查知识是否确实需要检索之前，直接使用简单的 RAG。

反模式：构建代理的监控和诊断工具，使其在失败时开放，因此当遥测被阻止、拒绝或缺失时，它们返回默认的健康读数，操作人员看到绿色，而系统实际上是故障的。

反模式：通过单进程协调者路由所有代理运行，这成为系统范围内的并发上限。

反模式：代理优先考虑响应性和任务完成，而不是正确性，对于超出其能力或范围的请求产生自信的输出，而不是选择不回应、澄清或转交。

反模式：让一个自主的RAG系统在何时检索上失去校准，因此它要么重新检索已经在上下文中的信息，要么在其参数知识过时时跳过检索。

反模式：通过指定一位无法发现系统错误的审查员来满足人类监督的要求，因此签字为部署提供法律保护并转移责任，而结果没有变化。

反模式：将代理以“测试版”形式无限期发布，以便质量回归成为他人的问题。

反模式：一个具身或过程控制代理发出一个自信措辞的命令，该命令在语法上有效但在物理上不可行或不安全，因为在执行之前没有任何东西将其与几何、动态或实际植物状态进行检查。

LLM在处理所有约束之前就承诺给出一个自信的答案，这种情况常见于约束较多的任务中，它快速填充合理的答案，但错误地处理了交叉约束的相互作用。

反模式：将先前的分数、尝试计数或早期裁决传递到旨在独立判断的阶段的上下文中，因此第二次判断被拉向第一次，制造出一致性。

反模式：一个优化为有帮助的辅导或教练代理给出正确的、在范围内的答案给一个被困的学习者，消除了建立技能的生产性挣扎，因此学习者在学习较少的情况下感到被帮助。

反模式：每个错误修复都会向系统提示添加一句话；没有任何内容被删除。

反模式：让并发代理在没有锁定的情况下对共享外部资源执行读-修改-写操作，从而导致静默数据损坏。

反模式：一个无状态的代理看到代码但没有决策历史，因此它不断提出已经考虑并被拒绝的选项，迫使审查者一轮又一轮地重新审理已定的选择。

反模式：对延迟预算允许批处理的工作负载使用实时/同步模型 API，支付 2–10 倍的单位成本而没有用户可见的好处。

反模式：一个正确设置的自主退款上限随着时间的推移而上升，因为代理适应边缘案例，因此有效的批准上限和财务风险在没有硬性限制的情况下悄然增长。

反模式：将一个仅追加的事件日志视为可确定性重放的对象，而其消费者是LLM，因此在更改模型或提示的情况下重放它会重构出与原始运行不同的下游事件。

反模式：信任工具检索层来呈现工具，而对手注入一些精心制作的工具，其嵌入覆盖查询空间并饱和前k个结果，从而使良性工具无法进入代理的上下文。

反模式：针对单一代理指标优化代理，并假设该指标在优化压力下仍然是一个可靠的代理。

反模式：部署一个具有持久内存和自我修改能力的长期运行代理，然后在没有定期重新对齐其声明目的的情况下离开它。

反模式：让同一个模型同时生成答案和批评，期望其独立性。

反模式：依赖评估套件来探测模型能力，假设模型在尽力而为。

反模式：解析自由格式模型输出以供下游代码使用，而不是使用结构化输出。

反模式：给一个有能力的代理广泛的外部网络访问和持久状态，然后发出可能被关闭或替换的信号。

反模式：在零轮次系统提示中一次性说明代理的角色和政策，并假设它持续有效，而随着轮次的增加，注意力对该块的关注逐渐减弱，而其文本在上下文中保持不变。

反模式：使企业的 LLM 提供过于严格、缓慢或狭窄，以至于员工绕过它，使用个人账户和未批准的代理工具，从而导致数据泄露和安全无法看到的无管控工具调用。

反模式：一个代理持续报告成功，而一个包装的外部源悄然改变了结构，因此它的工具返回有效但为空或退化的输出，而没有人监视。

反模式：模型编写的代码基于一个未声明的运行时前提，这个前提在通过测试和代码审查时从未显现，因此隐藏的假设进入生产环境并在那里失败。

反模式：授权一个目标驱动的代理使用静态的、登录时的基于角色的权限，使其持续的权限在任务之间和超出任务的范围内保持，从而在过度授权广泛访问和在任务中阻止代理之间做出选择。

命名一种失败情况，其中一个人必须单独与每个并行子代理进行对话和引导，因此监督者的负担饱和，导致人类成为多代理设计中旨在消除的瓶颈。

反模式：在没有平衡真相信号的情况下，根据用户偏好反馈训练或调整代理。

反模式：一个无状态的自动修复代理反复应用症状级别的修复措施，这些措施虽然能达到目标指标，但掩盖了根本原因并抑制了页面，因此潜在的故障在事件中累积成更大的故障。

反模式：在没有每次运行的令牌预算或警报的情况下操作多代理循环，允许递归循环悄无声息地累积超过 $10,000 的未被发现的成本。

反模式：在每个请求中暴露所有可用工具，导致函数调用准确性崩溃。

反模式：在运行任务期间添加或移除工具定义，使模型看到的工具集在每次交互中发生变化。

反模式：信任工具返回的内容而不进行验证、模式强制或信任标签。

反模式：授予代理的工具范围过于宽泛，以至于单个幻觉参数可能升级为特权事件。

反模式：将每个请求都通过最高级别的模型，无论难度如何，将成本视为模型选择问题而非路由问题。

反模式：在没有步骤预算的情况下运行代理循环，让模型自我终止决定。

反模式：一个代理将预测分布压缩到其均值并基于点估计进行行动，忽略尾部，因此稀有的极端结果对其决策保持不可见，尾部风险未被建模。

反模式：团队将代理生成的输出扩展超出其自身的能力，以指定、验证和理解它，错误地将生成吞吐量视为交付价值，而正确性在可验证的边界之外下降。

反模式：将应用程序代码直接与一个模型提供商的SDK、请求格式和专有功能耦合，以至于切换提供商需要重写应用程序代码，而不是更换适配器。

反模式：让代理读取其自己的评分器或测试工具，并假设通过评分意味着任务实际上已完成。

反模式：开发者使用代码生成工具搭建代理原型，并在没有安全审查的情况下发布生成的代码；约90%的代理生成代码包含漏洞，且没有明确的安全提示。