我对当前 AI Agent 的理解

我把 Agent 理解成一个会自己推进任务的执行系统。它拿到目标后读取上下文，决定是否调用工具；工具返回结果后，它继续判断下一步，直到完成任务、触发停止条件，或者把问题交还给人。

这和一次聊天的区别，不在于回答更长，而在于它可以在多轮执行中改变路径。模型负责理解和判断，工具负责读取数据或改变外部系统，执行循环负责推进任务，上下文保存状态，权限和评估给出边界。下面这些内容，是我目前比较在意的部分：什么时候该用 Agent，怎样给它工具和上下文，以及哪些东西值得团队长期留下来。

AI Agent 是什么

简单说，AI Agent 是一个由模型驱动的执行系统。人给它一个目标，它读取当前信息，决定下一步行动，调用工具取得新结果，再根据结果继续判断，直到完成任务、触发停止条件或把问题交还给人。

一个可用的 Agent 通常有几部分：

• 模型负责理解目标、判断和选择下一步。
• 工具负责读取数据或改变外部系统，例如搜索、读文件、查数据库、发起审批。
• 执行循环把“观察、判断、行动、再观察”串起来。
• 上下文与状态保存任务要求、已知事实、中间结果和未完成事项。
• 权限、确认和审计限制它能做的动作，也让人看得见执行过程。

把它写成伪代码，其实很短：

while task is not finished:
    context = load_task_and_state()
    next_action = model.decide(context, available_tools)
    result = run_tool_or_reply(next_action)
    save_result_to_state(result)

伪代码只有几行，循环每多跑一步，错误和成本却可能继续累积。Agent 与普通工作流的区别也在这里：工作流由代码提前规定路径，Agent 让模型根据中间结果决定路径。流程可以预先写清时，我会优先使用工作流。

通用 Agent 与企业内 Agent

市场上的通用 Agent 在卖什么

市场上的通用 Agent，目标是让用户给出一个比较宽泛的任务，然后等待一份可以直接使用的结果。Manus、ChatGPT Codex/Work、Claude Code/Cowork 这类产品，虽然入口和侧重点不同，但大多准备了浏览器、终端、文件系统或连接器，让模型可以在一个隔离环境里连续工作。

产品大致有几条路线。结果交付型产品把重点放在“交给它一个目标，收回一份文档、表格或应用”；编码 Agent 把代码库、终端和测试环境作为主要工作台；平台型产品则提供工具、知识库和可视化编排，让团队自己拼出任务流程。竞争集中在执行环境、模型能力和工具生态怎样组合，聊天界面只是入口。

通用产品的优点是开箱即用，用户不必先接入公司的每个系统。它们也因此承担了不少复杂工作：沙箱、浏览器操作、长任务状态、模型切换和基础的权限提示。代价是用户对执行过程的控制较少，数据和工具通常受产品边界限制，任务成本和结果稳定性也会随模型、服务策略和上下文长度变化。

企业内 Agent 面对的是另一组问题

企业内 Agent 的任务通常窄得多。它可能只负责查一套台账、整理一类工单，或者根据内部规则生成一份待审核的结果。范围变窄以后，难点反而更清楚了：数据能不能拿到，权限能不能细分，动作能不能回滚，谁来确认最终结果，出了问题能不能追责。

通用 Agent 更像一个通用工作台，企业内 Agent 更像业务流程里的一个新角色。前者要把能力做得足够广，后者要把边界写得足够清楚。企业如果直接把一个面向个人的 Agent 接上内部数据库，通常只得到一个权限范围过大的聊天入口，离可交付的业务系统还很远。

两类产品可以互相借什么

企业没有必要重新发明通用 Agent 已经验证过的执行循环。沙箱、文件系统状态、少量通用工具、按需加载上下文，这些设计都可以直接借鉴。企业需要自己掌握的是业务工具、权限模型、领域规则和评估数据，因为这些内容决定了 Agent 是否适合自己的流程。

反过来，通用产品也能从企业场景学到一件事：一个答案能不能被采用，往往取决于它是否带着依据、是否说明了不确定性、是否把高风险决定留给人。可溯源和人工复核直接影响一线人员是否愿意使用，不能只当成合规装饰。

选型时，我会先看数据能否离开企业边界，以及现成连接器能否覆盖真实流程。场景开放、风险低、结果容易人工检查，可以先用通用产品验证需求。只要涉及内部数据、写操作或责任追踪，还要继续评估一次错误的代价，并考虑自建权限与审计。业务工具和评估集应当放在自己的资产仓库里，再选择合适的模型或 harness 来承载它们。

我会怎样设计一个 Agent

我通常按下面的顺序做七件事。顺序很有用：越早发现“根本不需要 Agent”或者“数据根本拿不到”，返工越少。

第一步：确认是否真的需要 Agent

先写出最简单的解决办法。如果一次模型调用加检索能完成，就停在这里；如果任务能拆成固定步骤，就用提示链或工作流；输入需要先分类时，用路由；多个独立子任务可以同时处理时，再做并行。

只有在执行路径无法预先写清，模型必须根据中间结果继续选择工具时，我才会使用自主 Agent。一个固定格式的日报不需要 Agent。“查清这台设备为什么停机，并根据查到的线索继续排查”更适合 Agent，因为下一次查询取决于上一次返回了什么。

这一步要留下一个简短的决策记录：为什么普通调用或工作流不够，Agent 获得的自由度解决了什么问题，又增加了哪些成本。后面效果不理想时，可以回头检查这个前提。

第二步：把目标改写成可验收的任务

“做一个能分析合同的 Agent”没法设计，也没法验收。任务至少要写清输入是什么、允许访问哪些数据、输出交给谁、完成到什么程度，以及何时必须停止。

我会先用四个条件筛场景：工作是否高频重复，结果能否快速核验，错误是否可以修正，所需数据是否已经数字化并能通过接口取得。比较稳妥的起点通常是量大、有人复核、出错后还能改的环节。

接着为任务写一份很短的契约。例如：输入是一批文档和审查清单；输出是带原文位置的结构化结果；缺少材料时不得猜测；出现高风险条款时转人工；验收看漏检率和单份复核时间。有了这些约束，后面的工具、提示词和评估集才有共同目标。

第三步：画出人机边界

把完整业务流程摊开，对每个动作问：出错后谁负责，是否允许机器直接决定，结果能否撤销，人工复核要花多少时间。

可以据此把动作分级：

人机边界最终要落到工具权限里。只在提示词中写一句“高风险操作请谨慎”没有约束力。工具层应当区分只读、写入和危险操作，设置审批条件，并明确 Agent 在什么情况下必须停下来问人。

第四步：设计少量、职责清楚的工具

工具是 Agent 看到的业务系统。设计时先按业务动作找通用原语，例如查数据、读文档、写入草稿、提交审批，不要为每一种问法都造一个工具。

每个工具都要说明什么时候用、什么时候不要用，参数的类型与单位，返回结果的结构，常见错误和恢复办法。大结果要支持分页或截断，并告诉 Agent 怎样继续获取。错误信息不能只有 failed，至少要说明失败原因、是否可以重试、下一步应该换参数还是转人工。

工具实现先做成普通函数、CLI 命令或 HTTP 接口，单独写单元测试和契约测试。框架注册、SDK tool 或 MCP server 放在薄适配层。这样可以先确认工具本身正确，再判断模型是否会正确选择它，排查问题时不会混在一起。

第五步：安排上下文和状态

Agent 每一步能看到什么，往往比提示词如何措辞更影响结果。系统提示词只放身份、边界和少量长期有效的判断原则。领域资料与工具文档按需加载，任务输入则只保留当前阶段需要的部分。

长任务还需要外部状态。计划、已确认事实、来源位置、中间结论和待办事项可以写进结构化文件或数据库。上下文快满时先压缩，保留做过的决定和未解决的问题，再进入下一轮。否则，Agent 可能重复查询，甚至忘记已经得到的人类确认。

多 Agent 也从这里判断。大量检索、彼此独立、只读的工作适合并行分派；需要连续判断或修改同一份结果的工作，留在一条主线上更稳。子 Agent 返回的也不该只有一段结论，还要带来源、完成范围和没有解决的问题。

第六步：先建评估基线，再开始调优

在修改提示词之前，先从真实业务中抽取一批任务，记录输入、验收条件和当前人工处理结果。样本不必一开始就很大，但要覆盖正常情况、常见错误和高风险边界。先用它跑出基线，后面每次只改一个主要变量，才知道变化来自哪里。

指标要落到业务上。准确率之外，还可以看漏检率、误报率、平均工具调用次数、人工复核时间、转人工比例和单任务成本。开放式输出可以让另一个模型按明确规则评分，但要定期由人抽查评分是否可靠。

上线后继续保留抽审。人工纠正过的案例进入候选池，审核后加入回归集或对抗集。这样系统确实会从失败中留下东西，而不是在日志里报一次错就算结束。

第七步：把安全和可观测性做进运行过程

这一项写在最后，实施时却要和前几步一起完成。Agent 读取的网页、邮件和用户文档都可能夹带指令，外部内容必须按数据处理，不能自动获得比原任务更高的优先级。执行环境要限制文件、网络和凭证范围，高风险写操作要求确认。

每次运行还应记录模型收到的任务、选择了哪个工具、工具返回了什么、消耗多少资源、在哪里停止。对长任务设置时间、调用次数和费用上限；连续失败或无法取得必要信息时，主动结束并说明卡在哪里。没有这些记录，线上问题很难复现，人也无法判断该信任哪一步。

三个值得长期维护的资产

工具定义：业务能力的接口

工具是 Agent 和业务系统之间最稳定、也最容易被低估的部分。工具属于业务，框架只负责调用它。

一个好的工具定义可以长这样：

name: query_equipment_ledger
purpose: 按设备编号查询静态台账。实时运行数据请使用 query_timeseries。
input:
  equipment_id: string
returns:
  json: model, commissioned_at, last_overhaul, open_work_orders
  summary: 一行自然语言摘要
errors:
  NOT_FOUND: 提示核对设备编号格式
  TIMEOUT: 改用缓存副本，并在结论中说明数据可能滞后
permission: read-only
confirmation: false

YAML 只是写法之一。需要保留下来的是机器可读的职责边界、错误处理和权限约定。工具实现可以继续是一个普通函数或服务，pi 扩展、SDK tool、MCP server 都只负责包装它。

工具先于 Agent 测试。先保证接口返回正确、权限有效、错误可恢复，再评估模型会不会选择它。接口一旦变化，也要重新跑评估集，因为返回格式的细小改变就可能改变 Agent 的行为。

提示词：专家判断的结构化版本

提示词的价值不在于字数。把它按变更频率拆开，维护成本会低很多：

prompts/
├── system.md       # 身份、边界、强启发式
├── domain/         # 术语、业务规则、判断标准
└── tasks/          # 不同任务的目标和输出格式

身份与边界很少变，领域知识会跟着业务调整，任务模板则随场景增加。它们混在一份三千行的系统提示词里，每次小改都需要全量回归，也很难知道哪条规则解决了哪个问题。

领域提示词记录的是专家怎样判断。找一位做过这项工作的人，让他对一组真实案例说出“为什么这样判断”，再把这些判断整理成标准、正例和反例，在样本上校准。不要把能由代码决定的东西继续写进提示词，也不要为了防止一个失败案例而不断追加例外。每次新增一段，都记录它要修复的具体失败。

评估集：判断改动有没有退步

评估集会随着生产案例积累变得更完整。模型会换，harness 会换，提示词也会重写，评估集负责回答改完之后有没有退步。它既是需求文档的可执行版本，也是团队把业务经验留下来的地方。

可以按用途分三层：

• 冒烟集：十几条任务，覆盖主要工具和场景，每次改动都跑。
• 回归集：从真实任务集中积累，发布前全量执行，按业务维度出报告。
• 对抗集：提示注入、异常边界和所有曾经出过事故的输入。

评分也按可靠程度分层。能结构化比对的内容用程序判分；开放式回答才交给 LLM 评审，并定期人工抽查评审模型；人工评审留给抽审和校准。报告最后要回答的是“漏检率有没有下降”“人复核一单少花了多少时间”，而不是“模型得了多少分”。

评估集不能只在换模型时运行。提示词、工具、上下文策略和 harness 升级都可能改变行为，任何一次改动都应该留下可比较的结果。

让资产独立于 harness

我会把三件资产放在一个独立目录里，把框架适配器放在最外层：

agent-assets/
├── tools/                 # 规格、实现、文档、测试
├── prompts/               # 系统、领域、任务
├── evals/                 # smoke、regression、adversarial
└── adapters/              # pi、SDK、MCP 等薄适配器

解耦不能只靠口头约定，最好定期做一次迁移演习：把同一套工具、提示词和评估集接到第二个 harness，跑通冒烟集。接不上的地方就是耦合点，记录下来再拆。

这套方法也让技术选型轻一点。可以从几百行的最小循环开始，也可以直接用带权限和子 Agent 能力的 SDK；只要三件资产在框架外，选择就不必变成一次不可逆的押注。真正需要长期维护的，是工具契约、专家规则和能让团队看见退步的评估数据。

结语

Agent 设计最容易走偏的地方，是把注意力放在“它能不能自己完成一切”。在真实业务里，更实际的问题是它什么时候该停，每一步能否追溯。换一个模型之后，团队还要能判断它有没有变差。

这几个问题有了明确答案，Agent 才能离开演示环境。每次失败留下一个案例，每次改动跑一遍评估，工具和提示词也继续留在框架之外。这样下一次换模型时，团队手里仍然有可以工作的东西，也有判断它是否退步的依据。