在 Agent 工程里，Tool Calling 很容易成为最先被关注的能力：模型能不能发现工具、构造参数、发起调用，再把执行结果带回对话。演示阶段也常以此作为效果分界，一边是只生成文字的问答系统，另一边是能够查数据、写文件、建日程、发请求的 Agent。这样的区分有用，但如果产品判断停在这里，就会把“能执行一个动作”和“能持续推进一项真实工作”混在一起。
我在政企软件、产品和架构项目里更关心另一个问题：这次调用完成以后，事情有没有继续往前走。一次工具调用可以成功返回，业务工作却可能没有留下可承接的状态；Agent 可以生成一封邮件，也不代表它有权发送；系统可以读取几十份材料，也不代表它知道哪些信息与当前事项有关。企业落地中的大量差异，不在模型会不会调工具，而在工具调用前后还有没有完整的工作承载。
假设目标是“准备一次客户拜访”。问答 AI 可以生成客户背景、沟通提纲和问题清单；当 Agent 被允许访问邮件、方案、客户资料和日程工具以后，它可以查找历史邮件、调取旧方案、识别负责人变化和未兑现承诺，整理出本次沟通重点。拜访结束后，它还可以把新确认的信息写入待办和日程，保留未决事项，并为下一次跟进准备材料。这里发生的不是几次互不相干的自动化，而是围绕同一项工作的连续推进。
图 1｜Agent 参与的是同一项工作的后续推进
一、Tool Calling 解决了动作问题，但没有自动解决工作问题
工具调用把模型从“只能说”扩展到“可以做”，这是 Agent 工程的重要基础。没有工具，模型即使判断出下一步应该查询客户系统、读取文档或创建日程，也只能把建议写在回答里；接入工具以后，它才有机会触达业务系统并产生外部效果。Tools 解决的是能力可达性：某个动作有没有可调用的实现，所需参数能不能构造，执行结果能不能返回。
但工具调用的成功条件通常比业务工作的完成条件窄得多。接口返回 200，只能说明一次请求被受理；文件写入成功，只能说明产生了一个新文件；日程创建成功，也不能说明时间、参与人和客户承诺已经核对。工程上如果只记录“工具执行成功”，很容易把技术成功误判为业务完成，后续的人和系统只能重新检查一遍。
企业 Agent 需要同时处理四类问题：它知道什么、它能用什么、它被允许做什么、什么必须由人承担责任。对应到架构上，就是 Context、Tools、Authority 和 Responsibility。四者互有关联，却不能互相替代；把它们都塞进一个提示词或者一张工具清单，系统在小范围演示里也许能跑，进入多人、多系统和高风险业务后就会迅速失去边界。
二、Context 不只是 Prompt，而是当前工作的有效信息范围
Prompt 是一次交互中的指令表达，Context 则是 Agent 为推进当前工作可以依赖的有效信息范围。提示词可以写“帮我准备客户拜访”，却没有说明是哪一个客户、对应哪次机会、上次沟通停在哪里、哪些结论已经确认、哪些内容只是销售人员的推测。把更多文档一次性塞进上下文窗口，也不等于 Context 已经建立，只是扩大了模型本轮可见的信息量。
真实工作中的 Context 至少要包含目标、当前状态、历史结果和约束条件。目标回答“这项工作准备推进到哪里”；当前状态说明已经完成什么、卡在哪里；历史结果保留曾经做过的判断、动作和反馈；约束条件则限定时效、数据范围、权限、合规要求以及人的确认点。缺少其中任何一部分，Agent 都可能得到局部正确、整体错误的下一步。
仍以客户拜访为例，同一句“整理客户需求”，在初次接触、方案交流、报价后异议处理三个阶段的含义完全不同。初次接触需要区分事实、线索和假设；方案交流要对照已有能力与需求缺口；报价后则要识别客户异议是否影响范围、承诺和价格。若系统只看到用户当前输入，不知道工作处在哪个阶段，它生成的材料可能文字完整，却无法直接用于项目推进。
Context 也不是聊天记录的另一个名字。聊天记录按时间保存说过什么，工作上下文需要按当前事项重新组织什么仍然有效、什么已经失效、什么存在冲突、什么可以作为行动依据。工程上应让 Context 从工作对象、权限规则、知识来源和近期事件中组装出来，并保留来源与时间，而不是把整段历史对话原样回灌给模型。
三、Tools 提供能力可达性，能力清单不能代替业务设计
很多 Agent 项目会从工具目录开始设计：搜索、读取、写入、邮件、日程、审批、数据库查询都列出来，再让模型自行选择。这个方式适合验证连接是否可用，却不足以决定产品怎样运行。工具描述回答“如何调用”，业务设计还要回答“在什么工作中调用、使用哪一份数据、结果进入哪里、失败以后由谁接手”。
同一个工具在不同工作中的意义可能完全不同。读取客户资料用于准备内部讨论，通常只产生信息获取结果；生成正式报价则会牵涉版本、有效期、价格口径和审批关系；向客户发送材料还会形成外部表达。它们都可能由相似的文档或邮件接口完成，但业务效果、风险等级和可撤销性并不相同。
所以，工具层应保持相对稳定和通用，工作层负责解释一次调用在当前事项中的业务含义。系统不仅要返回原始结果，还要把结果映射为“材料已获取”“待核验”“草稿已生成”“等待审批”“已对外发送”等可识别状态。否则，工具越多，Agent 能制造的动作越多，业务人员反而越难判断事情究竟到了哪一步。
四、Capability、Authority、Responsibility 必须分层
技术上看，一个 Agent 到底能走多远，不能只问“它会不会调用”。更完整的检查方式是同时看四件事：它知道什么、它能用什么、它被允许做什么，以及什么必须重新回到人。下面这张图沿用客户拜访场景，把四个问题放在同一个工作目标下观察。
图 2｜Context、Tools、Authority、Responsibility 回答四个不同问题
Capability 描述系统具备什么能力，例如读取文档、生成报价、修改项目状态、发送邮件。Authority 描述某个主体在特定条件下是否被允许使用该能力，它通常与用户身份、组织角色、数据范围、工作阶段、风险等级和动作对象有关。Agent 能调用“发送邮件”工具，只能证明能力存在，不能推出它可以代表任何人向任何对象发送任何内容。
Authority 也不应只实现为工具接入时的一次开关。企业业务里的授权往往带有条件：可以读取本部门材料，但不能跨项目访问；可以生成报价草稿，但正式价格必须由指定负责人确认；可以创建内部待办，但对外承诺必须经过审批。把条件写进 Prompt 只能形成软约束，稳定的控制应落在身份、策略、数据过滤、执行网关和审计记录上。
Responsibility 回答的是动作产生后果时谁负责判断、确认和承担。它与 Authority 有交集，却不是同一个概念。某位项目经理可能有权批准材料发送，但客户承诺、合同边界或重大价格例外仍需业务负责人承担；系统也可能允许 Agent 自动归档邮件，却不能让模型对归档遗漏自行承担责任。
在高风险、不可逆、涉及正式承诺或敏感信息的动作上，系统不应只根据模型置信度决定是否继续。应明确哪些场景必须回到人、由谁确认、确认针对哪个具体版本、确认以后提交什么状态，以及后续怎样审计。人的确认点不是在流程中随意插入一个弹窗，而是责任边界的一部分；如果确认对象和后续效果都不清楚，点击“同意”并没有形成可追溯的授权。
五、Work State 决定一轮结果能不能被下一轮承接
当 Agent 已经能找资料、整理材料、调用工具、执行动作并返回结果，距离持续工作仍有一段关键距离。每轮结果必须进入工作状态（Work State），后续系统才能知道这项工作现在在哪里、哪些变化已经生效、下一步为何发生。只把结果显示在聊天窗口里，用户关闭页面以后，工作仍然停留在一次会话。
图 3｜会执行几个动作，仍然不等于能持续完成工作
工作状态不是给模型准备的一段摘要，也不是数据库里随便新增的一列 status。它应承载当前目标、阶段、已确认事实、仍待验证的假设、完成的动作及结果、未决事项、责任人、下一条件和关键时间。不同系统可以采用不同的数据结构，但这些信息需要围绕同一个可识别的工作对象组织，不能散落在邮件、聊天、文档和日志里靠人重新拼接。
执行结果进入工作状态之前，还需要一次结果校验。查询无数据可能是客户确实没有记录，也可能是权限不足、接口超时或检索条件错误；文档生成成功可能只是文件存在，并不代表必填内容完整；邮件已发送也需要确认收件人、附件和版本是否一致。没有校验就直接更新工作状态，会把技术异常写成业务事实，并在下一轮继续放大。
状态提交以后，下一轮才有稳定的起点。系统可以根据新状态判断下一条件是否满足，也可以在需要判断时重新组装 Context，让 Agent 继续分析；如果工作要交给另一个人或另一个 Agent，接手方也能看到同一份当前事实，而不是从头阅读所有对话。持续性来自状态的承接，不来自模型“记得很长”。
这也是聊天记忆与工作状态需要区分的原因。记忆可以帮助系统理解用户偏好、历史习惯或长期背景，工作状态则要准确回答一项具体业务当前发生了什么。前者可以辅助判断，后者必须成为后续动作、权限校验和责任追踪的依据，两者混在一起会让偏好被误当成事实，也会让已经失效的历史信息继续控制当前工作。
六、Skills 和 MCP：一个偏方法，一个偏连接
Agent Skills 可以把某类任务的做法、步骤、脚本、参考资料和模板组织成可复用的能力包。它适合沉淀“这类工作通常怎样做”，例如准备客户拜访时需要检查哪些材料、如何识别缺项、输出采用什么结构。Skill 提高了方法复用和执行一致性，但它不会自动获得业务授权，也不会天然知道某个客户项目的当前状态。
MCP 用于标准化 AI 应用与外部数据、工具和服务之间的连接与交互。按照当前官方规范，服务端可以提供资源、提示和工具，客户端与宿主负责建立连接和使用这些能力；截至本文核验时，MCP 当前正式规范发布日期为 2026-07-28。MCP 让接入方式更统一，却不会替业务系统决定一份数据是否属于当前工作、某个动作是否被授权，或者执行后由谁承担责任。
工程上可以把两者放到同一条链路里理解：Skill 提供某类任务的可复用做法，MCP 或其他连接方式让系统触达外部能力。它们能够显著降低 Agent 工程的重复建设，但完整工作系统还需要工作对象、Context 组装、Authority 校验、状态提交、异常处理和人的责任边界。把 Skill、MCP 或 Tool Calling 中任何一项单独等同于 Agent，都会遗漏其余运行条件。
七、Workflow 与 Agent 不是替代关系
讨论 Agent 时，经常会把 Workflow 描述成旧方式，把自主判断描述成新方式，仿佛两者只能二选一。实际项目中，大量关键环节仍需要确定性：材料归档必须进入指定目录，报价审批必须经过规定角色，接口失败要按规则重试或转人工，正式发送前要校验收件人与版本。这样的部分交给明确流程更可靠，也更容易审计。
Agent 适合处理路径无法提前完全列举、需要结合当前 Context 做动态判断的部分，例如从多份沟通记录中识别客户关注点、判断材料缺口、生成有针对性的拜访提纲、解释客户反馈可能影响哪些方案内容。它不需要取代整个流程，而是在流程中的判断节点、内容处理节点和异常分流节点发挥作用。确定性流程负责守住必须发生的步骤，Agent 负责处理难以用固定规则穷举的变化。
客户拜访的准备过程就可以采用这种组合。Workflow 创建拜访任务、绑定客户和时间、拉起材料检查、设置发送前确认点；Agent 根据当前项目状态阅读邮件与方案，找出矛盾和缺项，生成沟通重点；人在涉及承诺、价格和敏感表达时确认；执行完成后，系统把结果写回工作状态，再由状态触发后续跟进。流程没有因为使用 Agent 消失，反而为 Agent 的动态能力提供了可控的运行轨道。
八、从 Tool Calling 到持续 Work，需要一条完整链路
把前面的部分合在一起，一次可持续的 Agent 工作通常要经过九个相互衔接的环节。工作对象承载目标和当前状态；Context 组装为本轮判断准备有效信息；Agent 形成下一步意图；能力匹配找到可用工具；Authority 校验判断当前主体能否执行；必要时进入人的确认；工具产生外部结果；系统校验结果并提交工作状态；新状态再触发下一轮、等待条件或交接。任何一环没有落实，工作都可能在一次执行之后失去承接。
这条链路中，Tool Calling 位于中间，而不是起点或终点。调用之前要有工作目标、有效上下文和授权判断，调用之后要有结果校验、状态提交和后续条件。只建设中间的工具选择与执行，容易得到一个动作能力很强、工作承接很弱的系统：它每次都能做点什么，却需要人反复告诉它现在在做哪件事。
企业实现时也不必一次建设一个庞大的“全自主 Agent 平台”。可以先选一项边界清楚、持续周期适中、当前依赖人工拼接信息的工作，把工作对象和状态设计出来，再接入少量高价值工具，明确授权和人的确认点。等一轮结果能够稳定写回、下一轮能够基于状态继续发生，再逐步增加能力和自动化范围，这比先堆几十个工具更容易形成可用产品。
九、企业 Agent 设计检查表
下面这份检查表适合在方案评审、原型验收和上线前使用。它不用于判断模型参数是否足够，而是检查 Agent 是否具备参与真实工作的基本条件。若多数问题只能用“模型应该能理解”或“用户再提醒一下”来回答，系统还停留在单轮助手阶段。
- 是否有明确、可识别的工作对象，而不是只依赖一次会话或一个聊天窗口？
- 当前目标、阶段、已完成结果、未决事项和下一条件是否有统一承载？
- Context 是否来自当前工作的有效信息，而不是简单拼接全部聊天和文档？
- 系统能否区分已确认事实、工作假设、模型推断和待核验信息？
- 每个工具解决的能力问题、输入范围、输出含义和失败方式是否明确？
- Capability 与 Authority 是否分开，授权条件是否由运行时强制执行？
- 读取、修改、对外发布、正式承诺等不同效果是否采用不同控制策略？
- 哪些动作必须回到人、由谁确认、确认哪个版本，是否已经写清楚？
- 工具结果是否经过业务校验，再进入工作状态，而不是只看接口成功？
- 一轮执行结束后，系统是否知道为什么继续、等待、交接或停止？
- Workflow 的确定性步骤与 Agent 的动态判断是否各自有清楚边界？
- 发生异常、越权、信息冲突或模型判断不确定时，是否有可执行的降级路径？
- 关键输入、授权、动作、结果和人工确认是否能够追溯与审计？
如果这些问题能够被产品结构和运行机制逐项回答，Agent 才开始从“会执行动作”走向“参与持续工作”。它不需要拥有无限权限，也不需要把所有流程都改造成自主运行。更可靠的方向，是让模型在清楚的 Context、可达的 Tools、受控的 Authority 和明确的 Responsibility 中参与判断与执行，并让每一轮结果都成为下一轮可以承接的工作状态。
参考资料
- Agent Skills 官方规范：https://agentskills.io/specification
- Model Context Protocol 官方规范（当前正式版本 2026-07-28）：https://modelcontextprotocol.io/specification/2026-07-28
- 本文关于 Agent、Work、Authority 与责任边界的架构判断，沿用《AI Native 产品架构》及“AI Native 架构笔记”的既有研究框架。
