为终端构建高效的AI编码智体：脚手架、框架、上下文工程和经验教训（下）

2026年3月来自OpenDev的论文“Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned”。人工智能编码辅助领域正经历着一场从复杂的集成开发环境IDE插件到功能全面的终端原生智体的根本性转变。基于命令行界面CLI的智体直接在开发者管理源代码控制、执行构建和部署环境的位置运行为长期开发任务提供前所未有的自主性。本文介绍 OPENDEV一个用 Rust 编写的开源命令行编码智体专为这种新范式而设计。有效的自主辅助需要严格的安全控制和高效的上下文管理以防止上下文膨胀和推理能力下降。OPENDEV 通过复合人工智能系统架构 [103] 克服这些挑战该架构具有工作负载专用模型路由、将规划与执行分离的双智体架构、惰性工具发现以及自适应上下文压缩逐步减少旧的观测数据。此外它还采用一种自动化记忆系统用于跨会话积累项目特定知识并通过事件驱动的系统提醒来防止指令淡出。通过强制执行显式推理阶段并优先考虑上下文效率OPENDEV 为终端优先的 AI 辅助提供一个安全、可扩展的基础。。。。。。。继续。。。。。。工具系统智体与开发环境交互所使用的工具构成一个可扩展的生态系统它在全面性与上下文效率、安全性与灵活性以及内置工具与动态发现之间取得平衡。表 1 提供所有 35 个内置工具的完整目录将这些工具组织成处理程序类别的注册表架构包括多个类别文件操作、shell 执行、Web 交互、通过 LSP 进行语义代码分析、用户交互和任务管理、通过 MCP 进行外部工具发现以及子智体委托。纵深防御的安全架构涵盖所有类别。注册表架构和模式构建随着功能的增长扁平的工具命名空间变得难以管理硬编码的分发逻辑缺乏灵活性而没有结构的动态插件加载则不安全。替代方案包括硬编码工具集简单但无法在不修改代码的情况下添加功能和扁平动态加载灵活但混乱会导致命名空间冲突、缺乏组织性和难以进行安全管理。 OPENDEV 采用带有处理程序类别的注册表将工具组织成基于模式的处理程序类。三个独立关注点。如图展示该架构。工具系统将模式构建、分发路由和生命周期钩子分离成不同的组件。文件操作五个工具负责处理所有文件系统交互参见表 1 中的“文件操作”类别包括读写、结构化编辑和搜索。它们共同构成智体进行代码操作的主要手段。Shell 执行和后台任务有四种工具负责 shell 执行和后台任务管理参见表 1 中的“进程”类别。智体需要运行任意 shell 命令来进行测试、构建和系统交互但必须确保安全像开发服务器这样的长时间运行进程需要后台执行并捕获输出。run_command六阶段 shell 执行。如图展示该流水线它将每个 shell 命令处理六个阶段1安全门用于阻止危险模式且不可覆盖2命令准备自动确认包管理器提示并取消 Python 输出的缓冲3通过正则表达式匹配 16 种框架模式来检测服务器并将长时间运行的服务器自动提升到后台模式4在基于 PTY 的后台和管道化的前台之间进行执行分支并进行进程组隔离5输出管理采用 3 万字符的头尾截断和 100 毫秒的轮询6超时处理空闲时间限制为 60 秒绝对超时时间限制为 600 秒。基于语言服务器协议 (LSP) 的多语言语义代码分析六种工具通过 LSP 提供多语言语义代码分析参见表 1 中的“符号”类别分为两个只读导航工具和四个结构编辑工具。基于文本的工具可以搜索字符串但无法识别语义结构查找方法的所有用法需要区分方法调用和变量名、处理重载以及跟踪跨文件的引用。为每种语言构建自定义解析器是不切实际的因此 OPENDEV 采用通过标准语言服务器 [58] 集成语言服务器协议重用一个成熟的生态系统其中每个服务器都由领域专家维护。四层 LSP 抽象。如图展示该架构它分为四层逐步在面向智体的工具调用和特定于语言服务器的协议消息之间进行转换。智体工具层公开六种工具每种工具都接受文件路径和符号名称语言检测、服务器选择和协议转换由下层透明地处理。符号检索器提供一个统一的 API它使用 NamePathMatcher 将符号名称解析为位置支持精确匹配MyClass.method、部分路径匹配method 匹配路径以 .method 结尾的任何符号和通配符匹配My* 匹配 MyClass、MyModule。LSP 服务器包装器通过单例池处理语言检测30 多种文件扩展名和服务器生命周期每种语言一个服务器延迟启动并具有自动存活检查和崩​​溃后透明重启的功能。Solid 语言服务器通过子进程处理程序管理底层 LSP 协议该处理程序通过标准 I/O 使用 JSON-RPC 2.0 进行通信每个服务器有两个用于 I/O 的守护线程使用线程安全的请求 ID 和可配置的请求超时。每个语言服务器都扩展一个公共基类并添加特定于语言的重写初始化参数、忽略的目录、跨文件引用等待时间从而允许通过添加服务器类来添加新语言而无需修改核心框架。用户交互、任务管理和规划八种工具支持用户交互、任务管理和基于计划的工作流程参见表 1 中的“任务管理”、“用户输入”、“规划”和“完成”类别。它们构成系统的人机交互核心确保智体能够收集需求、汇报进度并在关键决策点获得批准。通过 MCP 实现高效的外部工具发现名为 search_tools 的工具通过模型上下文协议 [1] 提供高效的外部工具发现功能参见表 1 中的“发现”类别。通过搜索发现的外部工具随后通过 McpToolHandler 调用该处理器会将调用分派到相应的服务器。核心问题在于上下文效率一个包含 100 个外部工具的系统每个模式平均包含 200 个tokens仅工具定义就消耗 20,000 个tokens。包含所有模式会造成资源浪费完全排除外部工具则会限制系统功能。OPENDEV 采用延迟发现机制工具通过关键字搜索按需查找并且仅将已发现的工具模式包含在上下文中。如图展示三-组件交互。系统集成 MCP 以实现动态工具连接。用户通过管理命令配置外部工具服务器数据库客户端、API 服务等。系统维护一组已发现的工具其中仅包含显式搜索或先前调用的工具的模式。初始上下文不包含任何外部工具模式。当智体调用search_tools函数例如使用查询“数据库查询工具”时SearchToolsHandler会根据所有已注册的 MCP 工具名称和描述构建词汇表提取关键字长度为 3 个字符以上的标记并使用词汇表匹配对每个工具进行评分。匹配度最高的工具及其名称和描述将返回给 LLM。然后ToolRegistry通过discover_mcp_tool()函数将匹配的工具标记为已发现并将其模式添加到已发现工具集中以便下次调用 LLM 时包含这些工具。直接使用限定名称调用 MCP 工具例如mcp__github__create_issue会自动发现该工具无需事先搜索。McpToolHandler会将调用转发到相应的外部服务器并管理序列化和错误处理。子智体委托、技能和批量执行三种工具扩展智体的功能使其超越单工具调用用于复杂子任务的子智体委托、用于按需获取领域专业知识的技能加载以及用于提高多工具效率的批量执行。持久层持久层使用磁盘上的普通文件存储对话历史记录、配置、模型元数据和文件操作日志结构化数据使用 JSON 格式追加密集型数据流使用 JSONL 格式每行一个 JSON 对象而对于需要简洁性的情况则使用纯文本格式。无需外部数据库。所有持久状态都位于两个根目录下。用户全局状态设置、缓存、已安装的插件位于 ~/.opendev/ 目录下。项目范围状态会话记录、项目特定设置位于从项目路径派生的子目录下~/.opendev/projects/{编码路径}/其中项目的绝对路径通过将路径分隔符替换为短横线进行编码例如/Users/alice/myapp 变为 -Users-alice-myapp。这种分离确保关于一个代码库的对话永远不会与关于另一个代码库的对话同时出现并且项目特定设置不会在不相关的代码库之间泄露。会话存储每个会话都存储为两个文件一个 .json 元数据文件和一个 .jsonl 转录文件。元数据文件记录会话标识符、创建时间戳和最后活动时间戳、工作目录、标题和摘要但不包含任何消息。转录文件存储实际消息每行一条每条消息序列化为一个 JSON 对象包含角色、内容、时间戳、工具调用和令牌计数。将元数据与消息分离意味着列出所有会话以便向用户显示会话选择器只需读取较小的元数据文件而无需加载可能很大的转录历史记录。操作日志和撤销智体程序可能会出错它们可能会写入错误的文件、进行破坏性编辑或者删除用户不希望删除的文件。OPENDEV 不会要求用户使用版本控制命令手动撤销这些更改而是将每次文件操作创建、修改、删除记录在日志中并提供一键撤销功能。每条操作记录包含操作类型、文件路径、时间戳、唯一标识符以及操作前的文件内容。这些记录存储在两个位置一个内存列表用于在当前会话期间快速撤销以及一个位于会话目录中的 JSONL 文件 (operations.jsonl)用于持久保存。JSONL 日志采用尽力而为机制如果写入失败例如由于权限问题则会记录该失败但不会中断代理程序的工作。内存列表是撤销操作的主要数据源。当用户调用撤销功能时系统会从内存中的撤销列表中弹出最近一次操作并进行撤销已创建的文件会被删除已修改的文件会被还原到备份内容已删除的文件则会从已保存的副本中恢复。内存中的撤销历史记录上限为 50 条以防止内存无限增长。达到上限后系统会首先移除最旧的条目。实际上用户很少需要撤销最近十几次操作因此这个上限并未造成实际问题。撤销系统与版本控制系统协同工作而非取代它。它能够处理未提交的更改而无需用户了解 Git并且在智体出错后相比输入git restore命令进行快速更正操作更加便捷。配置配置遵循四层架构旨在确保用户开箱即用并可在适当范围内进行自定义内置默认值提供无需任何用户设置即可运行的配置默认模型、温度、自动保存间隔等。环境变量提供 API 凭据和 CI/CD 特定的覆盖设置。API 密钥仅从环境变量加载绝不会从配置文件加载以防止在版本控制中意外泄露。如果在配置文件中找到密钥则会在加载过程中自动将其删除。用户全局设置 (~/.opendev/settings.json) 存储跨项目的首选项例如用户首选模型、UI 设置和工具自动批准规则。项目本地设置 (/.opendev/settings.json) 存储特定于存储库的覆盖设置例如特定代码库的不同模型或项目特定的编码标准。提供商和模型缓存系统需要了解每个提供商提供的模型及其功能上下文长度、视觉支持、定价。OPENDEV 不会将这些信息硬编码到系统中而是从外部目录 API 获取并将结果缓存在本地的 ~/.opendev/cache/ 目录下。缓存采用“过期后重新验证”策略有效期为 24 小时。启动时系统会检查 .last_sync 标记marker文件的修改时间以确定缓存的上次刷新时间。如果缓存时间不足 24 小时则直接使用。如果缓存过期或缺失系统会从 API 获取最新数据将其转换为每个提供商的 JSON 文件每个提供商一个文件包含模型名称、上下文长度、功能和定价并更新标记marker。如果网络获取失败系统会回退到过期的缓存如果存在或者在没有可用缓存的情况下不使用功能信息继续运行。这样可以确保智体即使在离线状态下也能启动上次成功同步的缓存文件提供了足够的信息以正常运行。以终端为中心AI编码智体的开发借鉴代码智能、自主软件工程和交互式智体设计等领域丰富且快速发展的研究成果。代码生成和代码LLMLLM在编程中的应用已经从函数级生成以HumanEval [15] 和MBPP [6] 为基准发展到类级任务例如ClassEval [23]再到需要跨文件规划和多步骤推理的存储库级挑战 [47]。包括 DeepSeek-Coder [33]、StarCoder [48]、CodeLlama [72] 和 CodeT5 [87] 在内的专用代码学习模型 (LLM) 推动了这一发展而 CodeTF [11] 等统一工具包则为这一发展提供了支持这些工具包实现了跨模型训练和推理的标准化。同时检索增强生成 [44] 和强化学习弥合孤立生成与实际代码库规模任务之间的差距 [47]。OPENDEV 在此基础上将代码 LLM 嵌入到智体循环中从而提供在真实代码库中应用生成代码所需的导航、编辑和执行功能。自主问题解决SWE-bench [40] 定义了自主问题解决的任务催生了一个涵盖单智体、多智体和基于工作流的方法的研究前沿 [46]。单智体框架例如 SWE-Agent [94]率先实现自主文件导航和代码编辑而 AutoCodeRover [108] 和 HyperAgent [69] 则将其扩展到迭代优化和通用任务解决。多智体系统将问题分配给不同的专业角色MAGIS [78] 分配角色扮演协作CodeR [14] 引入任务图执行而 OpenHands [84] 等平台则通过集成选择 [46] 来协调异构智能体。基于工作流的方法例如 Agentless [89]强制执行结构化流程定位、修复、验证以提高可复现性。除了架构选择之外社区还探索基于训练和推理的方法来提升智体的能力。结合课程学习 [91] 和合成数据 [68] 的监督式微调以及利用面向过程的奖励的强化学习算法 [53]赋予模型更强大的问题解决能力。在推理阶段蒙特卡洛树搜索[112]能够灵活地回溯修复轨迹而诸如CodeMonkeys[86]之类的并行探索策略则能最大化解决方案覆盖率[46]。OPENDEV借鉴这些进展将单智体自主性与结构化的子智体委托和基于工作流的安全强制执行相结合。在这些范式中智体越来越依赖代码本身作为其推理和行动的主要媒介。代码作为通用智体的核心媒介最近的研究强调了从纯粹的自然语言推理到代码驱动的智体交互的范式转变[47]。使用代码作为通用媒介智体能够精确地调用工具、进行可复现的状态管理并拥有可组合的动作原语。交互协议。诸如ReAct[99]和ReWOO[92]之类的标准化工具使用模式能够实现精确的工具调用和状态管理。模型上下文协议 (MCP) [1] 引入结构化消息格式用于可靠的多轮工具编排而诸如智体到智体 (A2A) 之类的多智体协调方案则支持智体间的直接通信 [47]。以代码形式思考和行动。诸如程序辅助语言模型 (PAL) [27]、思维程序 [47] 和代码链 [47] 等推理方法使LLM能够生成和执行用于结构化推理的代码。动作执行框架将计划转换为可运行的代码CodeAct [83] 通过可执行的 Python 实现交互式操作TaskWeaver [71] 将请求转换为基于插件的函数调用而 CodeAgents [77] 则提供了额外的编排模式。领域应用将这种范式扩展到软件工程之外从医疗保健EHRAgent [36]到机器人控制代码即策略 [52]。以代码形式存储。基于代码的存储策略已被证明能够有效地管理 LLM 上下文约束。 Voyager [81] 将已验证的技能存储为可执行代码以供后续重用而 Reasoning Bank [54] 则支持从维修轨迹中进行基于规则的学习。MemGPT [66] 和 ExpeRepair [106] 引入用于上下文管理的分层和双内存架构。智体软件工程工作流智体软件工程规范化了人类工程师和LLM协作完成软件任务的工作流。Hassan [35] 提供一个全面的研究路线图其中确定包括智体编排、环境设计和生命周期管理在内的基础支柱。迭代式和提示驱动的工作流。计划-执行-评估-审查 (PDAR) 循环规范化单个任务的生命周期通过产品需求提示 (PRP) 进行规划、由开发智体执行、自我评估和人工审查 [35]。诸如 SuperClaude 之类的命令行工具包为这些循环提供了模板以确保一致性和便利性但并未提供团队层面的方法论。规范驱动的开发。越来越多的框架将结构化规范而非源代码视为人工智能辅助开发的主要真理来源。 GitHub 的 Spec Kit [31] 引入一个四阶段工作流程规范、计划、任务、实现其中正式的 spec.md 和可选的 Constitution.md 规范了所有由智体驱动的变更确保 AI 生成的代码符合明确声明的意图和架构约束。OpenSpec [26] 采用一种互补的“棕地brownfield优先”方法旨在演进现有代码库而非全新项目每个提出的变更都会生成规范增量以 GIVEN/WHEN/THEN 格式添加/修改/移除需求并与持久化的规范基线进行比较从而在编写任何代码之前即可对修改进行审计。这两个框架都与智体无关通过斜杠命令和文件系统约定而非特定于工具的 API 与 17 种以上的编码助手集成。多智体和敏捷框架。 BMAD [9] 进一步拓展团队隐喻将智体组织成敏捷角色产品负责人、架构师、开发人员、Scrum Master、测试人员并利用产品需求文档 (PRD) 和用户故事文件实现跨隔离 Git 分支的并行执行 [35]。一项关键的架构决策是工作分片Scrum Master 智体将任务分解成独立的用户故事文件每个文件都包含开发人员代理所需的确切上下文这种设计本身而非压缩方式解决上下文窗口的限制。更广泛的 SASE 路线图中一项重要的划分是将工作空间分离为智体命令环境 (ACE)用于人工监督和编排和智体执行环境 (AEE)用于可扩展的智体操作[35]。指导和生命周期管理。SASE 路线图 [35] 引入“指导即代码”的概念其中评审反馈转化为版本控制的、可测试的 MentorScript 规则从而实现跨任务的累积改进。智体生命周期管理将智体从无状态的承包商转变为具有内存、可观察性和安全执行能力的持久团队成员。智体工具系统和模块化组件在无需训练的框架中LLM依赖于专用工具来增强推理能力而无需进行微调。这些工具沿着修复流程组织缺陷重现、故障定位、代码搜索、补丁生成、验证和测试生成[46]。缺陷重现工具例如AEGIS[51]提供自动化的环境设置和重现工作流程确保执行上下文的一致性。故障定位工具包括基于频谱的故障定位SBFL和构建代码依赖关系图的基于图方法[46]。代码搜索工具涵盖从使用BM25和基于AST的API的交互式检索到通过知识图谱和语言服务器协议进行的基于图理解[46, 58]。补丁生成工具采用稳健的编辑格式例如AutoDiff并通过回归测试进行集成选择[46]。SpecRover[16]使用规范引导的搜索来生成高质量的补丁。诸如 Otter [109] 和 Issue2Test [82] 之类的测试生成工具使用反馈驱动机制来合成失败的测试以重现报告的缺陷 [46]。面向长时程智体的上下文工程上下文管理是长时程智体系统面临的一项根本性挑战。问题解决任务通常需要长时程、多轮交互这会增加 API 成本并因上下文腐化​​而导致性能下降 [46]。形式化基础和分类。Mei [56] 首次对长时程智体的上下文工程 (CE) 进行全面的综述将提供给模型的上下文形式化为一个结构化元组 C A(c_instr, c_know, c_tools, c_mem, c_state, c_query)其中 A 是一个组装函数用于协调指令上下文、外部知识、工具模式、内存、执行状态和用户查询。该综述围绕三个支柱组织该领域上下文检索从外部来源选择相关信息、上下文处理转换、压缩或重构检索到的内容和上下文管理在各个轮次之间保持一致性和相关性。历史和理论视角。Hua [39] 将上下文工程置于更广泛的知识史中追溯了其发展的四个阶段早期提示符工程侧重于单轮指令检索增强型生成引入了外部知识工具增强型智体扩展了动作空间以及当前将上下文视为首要工程问题的 CE 2.0 时代。借鉴 Dey 在普适计算中对上下文的正式定义以及 Weiser 的平静技术理念他们阐述三个指导原则熵减每个上下文元素都应降低对预期输出的不确定性、最小充分性仅包含避免注意力分散所必需的信息和语义连续性上下文应在对话轮次中连贯地演化而不是从头开始重建。他们还指出当前系统存在一个局限性即过度关注聊天历史管理而忽略工具状态、环境信号和跨会话知识等整体上下文维度。上下文处理和压缩技术。文献综述表明结构化上下文处理能够带来显著的量化收益[56]。思维链变型例如思维树[98]和思维图[8]通过构建中间上下文来改进多步骤推理而压缩方法则可以在不损失相应质量的前提下降低词元成本上下文自编码器[29]实现了4倍压缩而PREMISE在保持任务性能的前提下将提示长度缩短了87.5%。在检索方面Self-RAG[5]引入了自反思检索能够自适应地决定何时检索并评估自身的输出RAPTOR[73]构建递归树状结构的摘要用于层次检索GraphRAG则利用知识图谱结构例如HippoRAG[34]来提高复杂查询的检索精度。这些进展揭示一种根本性的不对称性LLM 在理解任务中对压缩上下文的鲁棒性比在生成任务中更强这表明积极的压缩策略最适用于那些为推理提供信息的上下文而不是那些直接影响输出文本的上下文。元-级上下文优化。Ye [101] 提出元上下文工程 (MCE)该框架将上下文工程本身视为一个优化问题而不是一项手动设计任务。他们将智体的上下文形式化为一个双层优化外层循环搜索上下文配置系统提示、工具模式、内存策略而内层循环评估智体在下游任务上的性能。一个关键的见解是固定的评估工具会给智体基准测试引入系统性偏差因为评估工具本身会以某种方式塑造上下文从而使某些策略优于其他策略。 MCE 通过使用带有交叉的 (11)-ES 算法来协同演化智体的上下文和评估设置从而解决这个问题。这种演化策略能够变异并重组上下文配置。在 SWE-bench Verified 测试中MCE 的解析率达到 89.1%而手工设计的基线算法的解析率为 70.7%同时由于上下文利用效率更高MCE 的运行速度也提高了 13.6 倍。优化后的配置可以跨任务迁移这表明元学习的上下文策略捕捉的是一般原则而非特定任务的特征。记忆整合使智体能够通过积累历史上下文来超越孤立的问题解决能力。相关方法包括将通用知识与特定存储库细节分离的分层存储[46]以及将知识划分为情景存储、语义存储和程序存储的认知架构[38, 56, 111]。基于上述记忆原语MemGPT的虚拟分页[66]、ExpeRepair的双-记忆[106]最近的研究探索群体层面的记忆智体变型群体[17]维护着多样化的探索历史以实现稳健的决策而经验库[85]则通过积累的知识来指导搜索。当前前沿研究优先关注提炼可迁移的推理策略从存储原始数据转向从轨迹中抽象出高级策略[46]。内存驱动的扩展方法通过集成持久上下文来减少冗余探索从而补充上述推理时策略使智体能够在过去的尝试基础上进行扩展而不是从头开始。针对长时域智体的上下文压缩技术取得显著进展ACON[41]针对延长的智体会话优化了压缩策略而Context-Folding[76]则通过递归上下文摘要扩展了智体的能力。在前沿领域智体上下文工程[107]使模型能够通过自我改进循环来演化自身的上下文。多智体通信通过一系列标准化协议的演进而日趋成熟从早期的知识共享语言KQML、FIPA ACL发展到现代互操作性标准包括用于工具集成的 MCP [1]、用于智体间直接消息传递的智体间通信 (A2A) 以及用于结构化多智体协调的智体通信协议 (ACP) [56]。智体编码系统评估基准在基准测试的范围已逐步扩大从功能和类级别的生成APPS [37]、CodeContests [50]到以 SWE-bench [40] 及其变体SWE-bench Verified [64]、Multi-SWE-bench [104]、SWE-bench Multimodal [96]、SWE-bench Pro [21]、SWE-Lancer [59]为基础的仓库级问题解决再到基于环境的交互任务例如 WebArena [113]、OSWorld [90] 和 EnvBench [24]。一些补充基准测试则针对特定维度SWT-Bench [60] 用于测试工作流FEA-Bench [49] 用于功能实现NL2Repo-Bench [22] 用于仓库生成DevEval [45] 用于完整的开发生命周期SWE-EVO [79] 用于长期软件演化。专门的基准测试评估的是除通用代码编辑之外的能力。τ-Bench [97] 和伯克利函数调用排行榜 [67] 评估工具使用和函数调用熟练程度。在科学和机器学习工程领域ReplicationBench [100] 针对研究复现MLGym [61] 和 MLE-Bench [12] 评估机器学习研究和工程任务而 CORE-Bench [75] 则衡量计算可复现性。对于长期终端交互Terminal-Bench [57] 表明前沿智体解决的精选 CLI 任务不到 65%而 LongCLI-Bench [25] 发现对于涵盖开发、功能添加、错误修复和重构的多类别编程任务通过率低于 20%。评估方法和最佳实践对智体系统进行严格评估需要精心设计基准测试而不仅仅是简单的准确率指标。智体基准测试清单 [114, 115] 正式定义最佳实践包括清晰的任务定义、可复现性保证、防止数据污染以及效率感知指标。诸如 MT-Bench [110] 之类的 LLM-as-Judge 方法能够在传统指标无法捕捉语义正确性时实现可扩展的质量评估但数据污染仍然是一个关键问题需要持续更新基准测试 [20, 93]。效率指标API 成本、推理时间和令牌消耗 [55]以及长任务完成时间测量 [42, 43] 为智体在实际部署中的实用性提供了全面的评估。人-智体协作LongCLI-Bench 提供令人信服的证据表明人机协作能够显著提高任务完成率。静态计划注入即在执行前提供关键计划在通过率和效率方面均优于自我纠错。动态交互式指导即智体根据其当前状态请求人类干预则能取得更高的性能。结合这两种方法的设置能够获得最佳结果同时减少对人类干预的需求[25]。这些发现有力地表明未来的系统不应仅仅追求完全自主而应开发协作工作流程以充分利用智体高效执行和人类战略指导之间的协同效应。OPENDEV 通过其审批工作流程、交互式命令执行和结构化反馈回路来支持这种范式。上述研究现状揭示一个清晰的发展轨迹从孤立的代码生成转向集成化的、长周期的智体系统这些系统必须在能力、安全性和上下文效率之间取得平衡。基准测试对真实环境下的持续多步骤推理提出了越来越高的要求而相关方法也在逐步解决此类持续运行所面临的工程挑战上下文管理、工具协调、内存和安全性。