你可能遇到过这样的场景测试失败了你把日志贴给 AI 助手它能解释错误甚至能猜到是哪段代码有问题。但接下来它停住了。它不能自己打开仓库、运行测试、读取文件也不能根据验证结果继续修复。你仍然要把每一步结果复制给它再等下一段建议。这不是模型不聪明而是系统形态还停留在 Chatbot。问题入口如果只看传统文本型 Chatbot它的基本形态仍然是用户输入文本系统返回文本。它可以有更长上下文可以接 RAG可以写复杂 prompt但架构上仍然主要是一次“请求-响应”的文本生成。Agent 改变的不是“回答更像人”而是系统开始承担任务。它不只回答应该怎么做还能在授权范围内读取文件、执行命令、调用服务、记录状态并把执行结果放回下一轮判断。会调用工具只说明有行动接口能否算 Agent要看工具调用是否进入闭环、是否受权限约束、是否能被追踪和复盘。这也是本篇想先澄清的边界Chatbot 和 Agent 的分界线不是聊天能力而是任务闭环。形态控制核心典型能力主要边界Chatbot文本生成回答、解释、总结不直接改变环境RAG 应用上下文来源检索资料后回答重点是答案忠实度Workflow 应用预设流程按固定步骤执行灵活性依赖人工编排Agent 应用受约束的行动决策多轮工具调用、观察反馈、任务推进需要状态、安全和审计这四类系统并不互斥。成熟 Agent 往往也包含 RAG 和 Workflow。区别在于控制权RAG 控制模型看什么Workflow 控制步骤怎么走Agent 让模型在约束内参与下一步选择。Chatbot 的边界问题在于开放式工程任务通常不是一次表达问题而是连续决策问题。用户说“帮我修复测试失败”真正的任务链路至少包括理解目标、查看项目状态、运行测试、读取日志、定位代码、修改实现、再次验证、说明改动依据。如果系统只能生成文本每一步环境观察都要由用户手动搬运。于是证据链断裂模型不知道仓库真实状态责任边界模糊危险建议没有经过权限检查任务无法持续系统不保存“已经做过什么、下一步是什么、失败在哪里”。因此Agent 不是在 Chatbot 外面多挂几个工具按钮。它需要把“说什么”推进到“基于什么状态、调用什么能力、产生什么结果、如何继续”。Agent Loop书稿里把 Agent 的基本结构概括为四个环节感知、推理、行动、反馈。感知让系统接收外部环境信息。这里的环境不只是用户输入还包括消息通道、文件系统、网络资源、知识库、历史会话和工具结果。推理让模型理解目标、选择策略、判断是否需要工具并解释观察结果。行动让系统在授权范围内调用工具改变外部状态或获取新证据。反馈让工具结果重新进入上下文驱动下一轮推理。这四个环节缺一不可。没有行动Agent 只是会说话的模型没有反馈工具调用只是一次函数执行没有感知系统无法接收环境变化没有推理工具会退化成固定流程。用“修复测试失败”这个例子看环节在任务中的含义感知接收用户目标读取仓库结构运行测试获得失败日志推理判断失败类型选择要查看的文件决定是否修改代码行动调用读文件、执行命令、编辑代码等工具反馈把测试输出、文件内容、修改结果放回上下文继续判断关键不在于某一次工具是否成功而在于工具结果能不能改变下一轮决策。Agent Loop 的价值就是让系统从“给建议”进入“拿证据、做动作、再判断”的循环。echo-agent为了不停留在抽象层面下面以 echo-agent 的实现为例。书稿中对 AgentLoop 的描述很直接它是核心处理引擎主路径是接收事件、构建上下文、调用 LLM、执行工具、发送响应。当前实现不是把所有逻辑塞进一个大函数而是编排 ContextStage、InferenceStage、ResponseStage 三个 Pipeline 阶段。ContextStage 负责“模型应该看到什么”。上下文不是历史消息拼接而是系统提示词、会话历史、记忆、知识检索、技能说明、工具定义和运行时元数据的组合。InferenceStage 负责“模型下一步要做什么”。模型可以返回工具调用系统执行工具再把结果作为 tool message 放回上下文进入下一轮模型调用。ResponseStage 负责“这次行动如何收束”。最终回复要发送给用户状态要写入会话重要事实可能进入记忆工具 trace 要保留下来。可以用一段简化伪代码表达这个闭环def handle_event(event): context ContextStage.build(event) ​ while not done(context): decision llm.call(context) ​ if decision.tool_call: tool_result ToolExecutor.run_with_policy(decision.tool_call) context.add_tool_message(tool_result) continue ​ return ResponseStage.finalize(decision, context)这段代码的重点不在语法而在控制权模型提出行动意图系统负责校验、审批、执行、记录再把结果交还给模型。LLM 是推理引擎Agent 是运行时系统。三元系统还可以把 Agent 理解为意图、状态与能力的三元系统。意图说明要达成什么状态说明当前知道什么能力说明系统能做什么。仍然看“帮我修复测试失败”要素具体落点意图修复测试失败而不只是解释日志状态当前仓库、测试输出、依赖版本、历史改动、用户授权能力读文件、跑测试、编辑代码、检索资料、提交结果说明只有意图没有状态系统会凭空猜只有状态没有能力系统只能描述现状只有能力没有意图系统就变成危险的自动化集合。生产级 Agent 的核心就是在每次循环中重新对齐这三者目标是什么证据支持什么判断当前允许使用哪些能力。工具执行很多 Agent 原型会把“模型能返回 tool call”当作完成点。但 tool call 只是行动意图还不是行动本身。真正执行前系统至少要回答几个问题工具是否可见参数是否合法是只读、低风险写还是高风险写是否触碰敏感路径或外部网络是否需要审批失败后能否重试或回滚结果是否写入 traceecho-agent 的书稿把这些约束放在工具注册、执行上下文、安全策略、风险分级、审批流程、路径策略、网络策略和 trace 记录中。它们是行动能力可托付的前提。自主性不是“想做什么就做什么”而是在目标约束下减少用户逐步指挥同时在高风险处停下来。这也是生产环境里的真实差别。Chatbot 说错一句话通常是答案质量问题Agent 做错一个动作可能影响文件、服务和数据。所以“生产级”不能只说得抽象。一个 Agent 至少应该具备可检查的工程项工程项要检查什么Tool call trace每次工具调用的参数、结果、错误和依据是否可追踪风险分级是否区分只读、低风险写、高风险写和外部可见动作审批节点高风险动作是否能暂停并等待用户确认失败恢复是否有重试、降级、回滚或明确停止条件状态持久化会话、任务进度、工具结果是否能跨轮保存评估回归关键任务是否有评估集和回归测试行动解释系统能否说明为什么采取某一步行动这些机制会增加复杂度但换来的是可托付性。没有它们工具越多风险越大。边界与取舍不是所有 AI 应用都应该做成 Agent。如果任务路径稳定、输入结构化、风险很高Workflow 往往更合适。审批流、财务入账、生产变更发布都更需要确定性。如果问题主要是“从文档中找答案”RAG 可能已经足够。它的关键指标是召回率、引用准确性、权限过滤和答案忠实度。Agent 适合开放式、多步骤、需要探索和试错的任务代码修复、资料调研、环境诊断、项目维护。它的价值不是替代所有流程而是把用户从机械步骤中释放出来。因此判断一个系统是不是 Agent不要先问模型多强、工具多少。应该问它是否能围绕目标持续感知环境、选择行动、接收反馈、更新状态并在风险边界内推进任务。任务闭环是 Agent 从“会回答”走向“能承担”的分界线。小结本篇只讲一个点Agent 的核心不是更会聊天而是形成任务闭环。Chatbot 以文本回复为中心RAG 以检索上下文为中心Workflow 以预设步骤为中心Agent 则以受约束的连续行动为中心。它需要感知、推理、行动、反馈也需要状态、安全和审计。echo-agent 在这里不是定义 Agent 的依据而是工程案例。它用事件入口、Pipeline、上下文构造、工具执行、审批策略和状态保存把抽象的 Agent Loop 落到可运行系统里。理解这一点后面再看上下文工程、工具系统、记忆、任务调度、多 Agent 协作和评估体系就不会把它们误解成模型外面的“附加模块”。它们共同服务的是同一件事让语言推理进入可控制、可追踪、可复盘的任务闭环。全篇完本文为 echo-agent 设计笔记系列第 01 篇。项目源码已开源至 GitHub。如果你对工业级 Agent 的工程落地感兴趣欢迎加入技术交流群QQ群号47572014参与日常讨论。下一篇我们将探讨 《AI Agent 的工程架构从能力分层到运行闭环》敬请期待。