把一件真实的客户跟进交给 Agent，背后是识别身份、查多个数据源、判断信息是否足够、等确认再执行的一整套动作。文章从产研视角拆解 Agent 的架构、薄 Harness 厚 Skills 与评测。

我们常说 2025 年是 Agent 元年，事实上今年小龙虾爆发后，大家对 Agent 的熟悉度才真正的起来了，那么到底什么是 Agent，也许我们今天可以来一个 2026 Agent 概述了！

把这样一个任务交给 AI：

看看这个客户最近的订单和沟通记录

判断他为什么迟迟没有续约，整理一份跟进建议

等我确认后，把消息发给他

这句话很短，背后却是一整套软件行为：

系统需要识别客户，取得访问权限，查询多个数据源，判断信息是否足够，生成建议，等待确认，执行发送，最后检查消息是否真的发出。

中间还可能遇到权限不足以及用户临时修改要求等问题。

Agent 要处理的，就是这一类需要根据现场情况不断作出判断的任务。

今年 Agent 很火，围绕它出现了不少新名词。站在产研的角度，更值得理解的是：这些能力如何组成可以工作的系统，我们常说的薄 Harness 厚 Skills 又是什么。

Agent 系统设计的核心，是把模型在运行中作出的判断，接到一个可验证、可恢复的执行过程里。

模型负责灵活理解与探索，程序保证执行规则，人承担关键决策与责任。工具、上下文、Skill、多 Agent、运行环境和评测，都围绕这条主线展开。

一、Agent 围绕任务组织能力

传统软件通常把能力拆成菜单和页面。用户找到客户，查看订单，翻阅沟通记录，再到消息系统里完成跟进。

流程中的行为，大量发生在人身上，软件提供功能，人负责把功能串起来。

Agent 接过了其中一部分组织工作。它理解目标，选择信息和工具，根据执行反馈调整后续动作。它的产品价值，可以概括为压缩用户和结果之间的这个中间层。

理解这个变化，首先要区分三个东西。

大模型提供理解、推理和生成能力。工具让系统取得信息、执行操作。Agent 则通过运行机制，把模型判断与工具执行接成循环：

例如，搜索结果不足时继续补查，发现订单与沟通记录冲突时核实，满足任务要求时停止。这里存在运行中的决策。

工作流会提前组织控制路径：先查询，再分类，再生成报告。Agent 则把部分路径选择交给模型，让它根据反馈继续判断。这是一种有用的架构区分，实际系统可以组合使用两种机制。

因此，讨论 Agent 时，核心问题也就出来了：任务中哪些决定能够提前确定，哪些需要现场判断，以及这些判断出错会造成什么后果。

一个规则清楚的报销流程，完全可以把节点固定下来，在票据理解等位置使用模型。一个复杂的故障排查任务，则可能需要不断读取新证据，调整排查方向。自主程度应当跟着任务需要变化。

企业系统也会继续承担重要职责。CRM、ERP 除了保存客户、订单和库存，还负责业务校验、事务和权限。Agent 可以在它们之上组织任务，也可以直接成为现有系统的一部分。

Agent 为软件增加了任务执行能力，原有系统中的业务事实与执行规则，仍需要可靠地维护。

这也解释了 Coding Agent 为什么容易成为一个观察样本：代码库提供上下文，终端和脚本提供行动能力，测试与构建产生反馈，版本控制帮助恢复代码改动。

换到企业业务，这些条件往往需要重新建设。资料可能分散在不同部门，接口未开放，业务标准只在专家脑子里，一些动作还无法撤回。

判断一个场景适不适合 Agent，可以先看四个条件：信息能否取得，工具能否使用，结果能否验证，失败能否恢复。

这比从无脑使用 Agent 架构，更容易得到清楚的设计。

二、架构关系与运行过程

要去理解 Agent，可以先把整个系统放到一张职责图里：

Harness 组织一次次判断与执行，Runtime 承载实际操作，业务系统保存需要落地的事实。

围绕这条关系，任务控制提供边界，资料与状态提供依据，观测与评测提供改进所需的证据：

这四组职责分别回答四类问题：

这是组织系统设计的一种方式，不要求拆成四个服务：

1. Runtime 中运行的工具可以访问业务接口、读写文件；
2. 上下文管理决定哪些资料进入模型；
3. 执行记录再进入观测与评测。

图中的反馈，也包括根据评测结果调整配置、验证新版本的过程。

Harness 可以理解为围绕模型工作的执行与控制机制，包括上下文装配、工具调用、循环控制、暂停恢复、权限检查与运行记录，不同实现会有不同边界。

Runtime 则回答资源问题：命令在哪台机器上运行，依赖装在哪里，文件怎样保存，浏览器消耗谁的资源。

有了这张地图，再让客户跟进任务完整跑一遍。

系统先确认用户身份和任务约束，准备当轮上下文。模型要求查询订单，程序校验后执行，再把结果交回模型。模型发现缺少沟通记录，继续补查；信息足够后生成建议，等待用户确认；批准后执行发送，再交付结果。

在自定义函数调用中，模型提出请求 → 应用执行 → 结果交回模型是基本机制；提供方内建工具也有相应的执行服务：

第一张图表达系统关系，第二张图表达一次执行。把两者分开，后面的设计就容易定位：工具问题影响行动，上下文问题影响判断依据，恢复问题影响任务持续，评测问题影响验收。

还要把交流记录与任务状态分开。用户可以换一个对话继续同一项任务；一次任务也可能因失败产生多次运行。系统需要追踪目标、已执行步骤和已经产生的业务效果。

用户说“接着做”，应该能够恢复明确的任务状态。模型返回“完成了”，则要继续核验交付物与业务状态。

Agent Loop 是推进任务的循环，验收机制决定这个循环什么时候有资格结束。

三、工具需要行动反馈

给 Agent 接入接口，真正的难点在于把接口变成它能够准确选择、正确使用、理解反馈的能力。

模型并不知道研发脑子里的业务背景。它通常依据名称、描述、参数和历史结果选择工具：

假设有三个工具，分别叫智能查询、增强查询、高级查询。这些名字没有说明什么时候使用，模型就很难稳定选择。

更清楚的设计，是按业务职责表达：根据订单号查当前状态，根据客户和时间范围批量查订单，或者检索公开资料。工具说明还要交代不适用的情况，避免能力重叠。

工具描述同时承担了使用说明和选择规则的职责。描述模糊，会直接变成运行中的选择成本。

数量也需要围绕任务收敛。把每个底层接口都原样暴露出来，可能让模型反复寻找；把所有操作塞进一个万能工具，又可能让参数复杂得难以理解。合适的粒度，要通过真实任务验证。

输入方面，可以把确定性的转换留给程序。

用户说“发到项目群”，模型表达目标，系统解析候选对象、检查权限、映射内部 ID。同名对象无法唯一确定时，返回候选项或要求澄清。模型可以继续使用工具返回的稳定 ID，但应减少凭空构造、反复转抄复杂标识的负担。

工具返回的内容，不只是执行结果，也是 Agent 下一轮判断的依据。只告诉它失败了，却不告诉它失败在哪里，下一轮就只能继续猜。

一个 success: false，通常不足以支持恢复。身份过期、查询为空、版本冲突和网络超时，需要的处理方式并不相同。

以群聊为例：Agent 看完第 142 条消息，开始组织回复；等它准备发送时，群里已经出现第 144 条消息。新内容可能改变原来的判断。

发送接口可以要求携带已读取的消息版本，在执行时检查状态。发生冲突时，返回类似这样的信息。以下是一个简化的设计示例：

{

“status”: “conflict”,

“code”: “STALE_CONTEXT”,

“observed_version”: 142,

“current_version”: 144,

“next_action”: “读取新增消息，重新判断是否发送”

}

是否遇到新消息就拒绝发送，可以按产品场景决定。这个例子说明的关键是：

Agent 的决策基于一个状态快照，执行时要判断这个快照是否仍然有效。

但版本校验还要考虑任务能否继续推进。假如群里一直有人发消息，每次发送都因序号变化被拒绝，Agent 就可能一直刷新，迟迟发不出回复，所以真实业务会涉及很多策略设计。

防止过期执行，与保证任务继续推进，需要一起设计。

这类问题同样会出现在库存调整、订单处理和多人跟进客户中。

执行还需要可信的身份，用户确认也要绑定具体动作。批准向某位客户发送某段内容，不意味着收件人和内容改变后仍可直接发送。系统需要保存确认记录，并在执行前核验。

MCP、CLI、Bash 都可以帮助组织行动能力。MCP 规范能力的发现和调用，CLI 把能力封装为命令，Bash 等 Shell 能够组合命令和运行脚本。MCP 可以本地运行，CLI 也可以访问远端服务。

它们怎样封装，不会改变执行端的责任。工具提示帮助模型理解能力，实际的文件、网络和业务权限仍要由程序约束。MCP 规范也明确要求服务端进行输入与访问权限校验。

一个工具是否设计完整，可以沿四个环节检查：选得对、调得动、读得懂结果、失败后知道如何处理。

四、上下文管理

客户跟进任务中，模型需要知道客户是谁，当前订单怎样，最近沟通过什么，哪些要求已经确认。

这些信息共同构成当轮决策的上下文。上下文工程要解决的，就是信息从哪里来、怎样组织、何时更新，以及怎样让后续执行继续使用它。

企业里许多看似模型不懂业务的问题，实际发生在信息进入模型之前。

“退款”指申请退款，还是已经退回资金？“本月销售额”按下单、付款还是确认收货计算？两个系统中的客户名称是否代表同一个对象？

口径不清楚，模型很难替组织自动达成共识。检索能够把相关资料找出来，资料本身仍然需要明确的语义。企业 Agent 因此经常需要进入数据治理和业务规则整理：

还有一些判断依据，根本没有进入正式业务系统。

客户经理为什么认为某个客户还值得跟进，供应商为什么不愿按原数量补货，这些信息可能还在聊天、Excel 或 Word 里。系统记录了最后的结果，未必记录形成结果的过程。

因此，企业 Agent 的信息建设，还要逐步取得业务人员实际使用的规则与判断依据。接通数据库只是其中一部分。

把信息接通之后，还要控制进入上下文的方式。

一份十万行的订单数据，可以保存在文件或数据库里，让程序过滤聚合，再把结果和出处交给模型。这样既减少反复传递，也把确定性计算交给了更适合的执行方式。

判断所需的信息要充分，信息进入上下文的方式要有选择。

长任务还会不断产生历史。压缩能够减少体积，但必须保住后续执行需要的东西：原始目标、最新约束、已确认的决定、失败原因、未完成事项，以及重要证据的地址。

一段已经完成前期分析的摘要，没有说明哪些信息已经核实，也没有说明接下来等谁决定，很难支持可靠恢复。过度压缩可能丢掉后来才显得重要的细节，这也是官方上下文工程实践明确讨论过的问题。

为避免混淆，可以把四类信息分开管理：

任务状态记录现在做到哪里。业务知识解释规则与方法。长期记忆保存适合跨任务使用的稳定信息。执行存档保存原始结果和日志，供追溯和重新读取

它们的更新方式不同。一次出差地点不能轻易写成长期住址；聊天摘要中的付款状态，也不能替代执行前对订单系统的查询。

记忆是帮助继续工作的派生信息，关键业务事实要能够回查。

信息还要有可见范围。个人偏好、客户资料、团队规则和公司知识，不应因为接进了同一个 Agent 就自动相互开放。任务委派给子 Agent 时，也要明确可以传递哪些信息。

外部资料的身份同样重要。网页、邮件可以提供证据，其中夹带的指令不应获得系统规则的权限。来源、内容与授权需要分开理解。

最后，上下文建设还包含维护工作。设计文档与代码不一致，知识库里并存多个互相冲突的版本，都会使模型判断更加困难。

接入能力可以一次完成，信息的新鲜度、语义和一致性需要长期维护。

五、Skill：业务判断与过程调整

工具回答能够做什么，Skill 进一步说明这类事情应该怎样做。

例如，搜索工具可以找到海外达人，但“找到适合某个品牌的达人”还需要判断：在哪些平台搜索，怎样组合关键词，哪些账号需要排除，如何判断活跃度和匹配程度，数据不足时是否继续补查。

这里比较难的，经常又是那些老大难的标准问题：到多少，它算是好的，到多少它算是坏的。这些阈值、例外和证据要求，才是值得沉淀的经验。

写出“搜索、筛选、生成报告”不难。难的是告诉它：什么情况应该补查，什么情况可以淘汰，什么情况必须回来问人

我们之前参与过的一个出海营销 Agent 的实现，就经历过几次调整。

最初尝试让模型直接生成代码完成工作。文档转换等相对简单的任务可以做，但串联较长的业务步骤时，稳定性不足。随后把流程接成外部工作流，封装给 Agent 调用，执行路径变得明确，却又难以让 Agent 理解和调整内部环节。

再把能力拆成工具，也没有直接结束问题。固定路径容易保证顺序，用户却希望在中间改变条件；完全临时编排又会增加不确定性。最终需要在步骤组织、工具粒度与模型判断之间重新分配职责。

这里的冲突很具体：用户既希望任务稳定完成，又希望已经完成一半的工作可以修改。总之这不是个确定性问题而是个权衡的问题：

咨询报告能把这个问题展示得更清楚。一个用于企业咨询交付的 YouTube 分析流程，需要收集参数、抓取视频与评论、清洗数据、检查资料范围、调整分词，最后生成洞察报告。

分析师会先检查抓到的视频是否相关，再检查分词和分析结果。报告中的稳定格式与可视化部分，可以交给脚本生成。这类交付需要“每一步都要有可解释性”，因为结论还要交给客户使用。

假设分析师看完分词结果，要求把两个词归并，再重新查看结论。这是对一个已有环节的修改，未必需要重新抓取视频。

但如果系统只保存了最终报告，内部流程又封成一个从头跑到尾的工具，它就缺少从中间继续的条件。模型知道用户想改什么，也不代表执行系统能够局部重跑。

要支持这个需求，就需要保存原始数据、清洗结果、分词参数和对应的中间产物，并说明各阶段之间的依赖。

修改分词，只重做受影响的分析与报告；如果修改的是视频筛选条件，就需要重新确认资料范围，再更新下游结果。新报告还要关联新的参数和数据版本，避免旧结论混入新产物。

Workflow 管理相对确定的依赖与执行约束，Skill 组织可复用的方法，模型处理需要根据结果继续判断的部分。三者可以在同一项任务中协作。

在实现上，Agent Skills 已有开放格式规范。名称和描述帮助发现能力，正文提供操作方法，脚本、参考资料和模板按需要加载；具体注入、执行和权限机制，由宿主实现。

名称和描述因此也参与路由。两个 Skill 的触发条件很相近，Agent 可能来回读取；任务最后做完了，时间却花在反复选择上。应当明确各自的任务、输入、输出与转交条件。

拆分则要围绕可独立执行、检查和重跑的业务步骤。过大的封装难以调整，过碎的拆分会增加选择与组合成本。

可解释性也来自可复查的证据：数据出处、筛选条件、中间产物和执行记录。模型事后生成一段合理解释，无法替代这些东西。

这也是 Skill 设计深入业务后，必然会遇到的一步：把人原来可以凭经验回退、修正和继续的工作，变成系统也能够操作的过程。

六、多 Agent 与信息的分工

当一个 Agent 要处理的任务变多，容易想到再加几个 Agent，这可能是常见的工程错误，这可能会增加复杂度…

增加执行者之前，需要先回答：这些工作能否独立进行，各自需要什么信息，结果由谁接收，怎样证明完成了。

几个相互独立的市场调研，可以分头读取资料，再由主 Agent 汇总。每个子 Agent 维护局部上下文，也能减轻主流程的信息负担。

如果多个任务密集依赖同一份最新状态，协调成本就会上升。几个 Agent 同时改同一个订单，或修改相互依赖的代码，分工之外还要处理一致性。

因此，委派一个子任务，至少应当给清楚目标、范围、输入、可用工具、输出格式和验收条件。

“帮我研究一下”容易带回一篇需要重新理解的长文；要求明确的证据、结论字段与待确认事项，更有利于后续整合。

多个执行者写入共享资源时，还需要划分所有权。可以使用独立工作区、对象版本检查，或者指定一个执行者负责最终提交。不同项目可以选择不同机制。

验证者则应该读取实际产物、测试结果或业务回执。如果它只看到执行者的自我总结，就可能再次认可同一个错误。换一个模型，也不能保证错误相互独立。

多 Agent 带来的并行性，需要用清楚的任务边界、信息交换与验收机制来兑现。

另外，产品里长期存在的写作助手、销售助手，与执行中临时产生的子 Agent，是两个设计层面。长期对象方便用户积累上下文和持续使用；临时委派用于完成某次任务。它们不必在界面上呈现为相同形态。

是否拆成多个 Agent，最终仍要回到任务集上比较：质量改善多少，时间缩短多少，额外增加了多少调用与协调成本。

七、生命周期

一次任务能够跑完，并不代表它已经具备持续运行的条件。

用户关掉页面，任务是否继续？确认流程停了两个小时，怎样恢复？执行进程重启后，哪些动作已经完成？发消息时超时，应该再发，还是先查结果？

这些问题需要任务状态、执行记录和调度机制共同解决。

任务至少要能区分排队、执行、等待确认、暂停、失败、完成和取消。每种状态都应说明当前在等什么、谁能处理，以及允许采取哪些后续动作。

等待人工确认时，可以保存恢复所需的信息，释放暂时不用的执行资源，收到确认事件后再继续调度。重启时则根据检查点和操作记录，判断从哪里恢复。

这里需要特别小心有外部效果的动作。生成一份草稿可以重新计算；修改订单、付款和发送消息，要先确认此前是否生效。超时或取消，也不能证明旧执行者已经停止。恢复任务时需要防止旧、新执行者重复写入。

可靠恢复需要同时保存工作进度与已经发生的业务效果

运行环境的选择也要围绕任务。

本地环境接近用户文件和桌面工具，云端便于持续执行和集中调度。沙箱用于约束执行边界，可以放在本地，也可以放在云端。这几个概念分别回答资源位置与隔离方式。

轻量查询任务可以与业务服务共用一部分资源。长任务、浏览器操作和较大并发，则更需要考虑隔离，否则执行端可能挤占交互服务，造成任务在跑、用户却进不去的情况。

预算要进入任务控制。运行时间、步数、费用、并发和重复失败次数，都可以设定限制。连续遇到相同错误时，系统应当暂停、改变策略或交给人处理。

模型能力提高后，一些用于弥补判断能力的复杂提示和绕行流程，可以重新评估。鉴权、审计、资源隔离和业务事务，则仍是系统要履行的职责。

这也是产研设计时应该保留的一条边界：模型有能力继续尝试，不意味着系统应该无限允许它继续执行。

八、Agent 评测

我们无论做什么，都需要优先确定好坏的标准，做 Agent 也是如此，很多同学做评测模块喜欢后置，但其实评测应该从需求阶段开始。

产品定义典型输入、任务类型和预期结果，研发明确可用能力与执行约束，测试把它们组织成能够重复运行的用例。这样，希望 Agent 很智能才能变成可以验证的交付要求。

企业任务可以先按下面四类理解：

复杂任务可以同时包含几类。开篇的客户跟进，就跨越了查询、分析和执行。

验收时，要分清工具返回、任务结果和业务收益。

接口返回成功，有时只表示已经受理。Agent 回复“发送完成”，也不能替代实际发送回执。

任务完成的证据，应该能够在产物或业务状态中找到。

过程也有必须遵守的条件。例如，发送前是否取得有效确认，是否访问了权限范围以外的数据，是否产生重复操作，这些约束需要进入评测。

至于合法路径本来就有多种的任务，则不必强求完全一致的工具顺序。先看订单还是先读沟通记录，可以不同；目标是否达成、约束是否遵守、成本是否合理，才是主要判断。

Trace 用来记录执行过程，帮助定位失败。它应当能关联输入、配置版本、信息来源、工具请求、执行结果、确认记录和最终状态。它提供可观察的运行证据，并不等于模型内部推理的完整记录。

有了这些信息，团队才能区分：对象找错了、工具选错了、参数填错了、接口失败了、上下文丢约束了，还是授权没有传递到执行端。

修复位置不同，处理方式也不同。把所有失败都归为“模型不行”，会让项目失去可迭代的空间。

评分方式同样需要组合。能够确定检查的字段、金额、状态和权限，用程序核验；语义和报告质量，可以用 LLM Judge 辅助；业务专家通过样例与抽查校准判断。

指标方面，先看端到端任务通过率、完成时间与交付成本，再用意图识别、参数正确率、工具成功率、无效调用和人工介入等过程指标解释原因。

通过率必须说明分母和任务构成。大量简单任务的成功，可能掩盖少数关键任务的失败。不同类型要分别观察，重要约束单独设门槛。

一次成功也只能证明这一次成功。重复运行有助于观察波动；涉及写入时，要在隔离环境中恢复约定的初始状态，避免前一次执行改变下一次的条件。

改模型、Prompt、工具或 Skill 时，应记录版本并运行回归。已用于反复调试的用例之外，还要保留未参与调试的样例，检查改善是否能泛化。

线上失败则应继续进入数据集，经过归因、修复、验证，形成下一轮迭代。

评测的价值，是让每一次改动都有可比较的依据，让系统能够积累进步，同时控制退化。

九、结语

今天内容已经很多了，我们来做一个总结：之前我们做任务是使用 Workflow，但现在我们慢慢开始选择使用 Agent，其实想要提升工作流的泛化能力。

而如何保证 Agent 执行过程的稳定性，这就是整个技术架构的真正发展脉络，更多也不说了，现阶段大家能够理解好什么是 薄 Harness 厚 Skills 就够了…