你的LLM不应该是你的编码智能体工作流
摘要
主张在编码智能体工作流中,LLM应仅用于推理,而由确定性基础设施处理队列、状态、重试和恢复,这样即使达到使用限制,流程也不会中断。
如果你的编码智能体工作流在达到LLM使用限制时停止工作,那说明LLM做得太多了。我是在使用OpenClaw构建时学到这一点的。模型应该对工作进行推理,而不应该成为工作流本身。队列、状态、重试、调度、验证、回执和恢复都可以以确定性的方式持续运行。只有在真正需要判断时才调用LLM。这种分离正是将编码智能体循环从“不断提示它”转变为真正可运行的基础设施的关键。
相似文章
我认为LLM不应成为代理运行时的核心
作者反对将LLMs作为代理运行时的核心组件,提出在处理请求时采用确定性和语义路径的分离,并寻求对这一架构想法的反馈。
选择大语言模型擅长与不擅长的任务
该文章强调,大语言模型在处理模糊判断任务方面表现卓越,但在执行一致性计算时表现平平,因此主张在多智能体系统中实现任务专门化。
超越LLM:为何可扩展的企业AI落地依赖于Agent逻辑
IBM Research探索了Agent逻辑——诸如知识图谱和程序分析等软件原语——如何引导基于LLM的Agent高效处理复杂的企业工作流,减少幻觉和成本,同时改善结果。
你的LLM提示词有200行。你真的知道智能体遵从了多少吗?
本文讨论了在生产环境中评估和监控基于LLM的智能体所面临的挑战,涵盖离线评估、提示工程陷阱、可观测性工具、审查队列、标注、聚类、主题分类,以及将人工审查、LLM作为评判和小型分类器进行成本分层的方法。
软件工程师:说正经的,你们真的从LLMs中有所收获吗?
一位软件工程师对使用本地LLM进行智能编码感到沮丧,指出诸如技术债务、忽略指令和过度生成代码等问题,质疑其有用性。