月末结账时，财务人员把银行流水、支付渠道流水和 ERP 导出文件交给 Claude Code 或 Codex，再加载一份描述公司对账规则的 Skill。Agent 读取 Excel、CSV 和 PDF，运行匹配脚本，识别疑似拆单、合单和跨期到账，最后生成一份异常报告。
这个 Demo 看起来已经相当完整。模型会推理，Skill 提供领域知识，MCP 或其他工具连接外部系统，Agent 还能根据工具结果继续行动。如果这些能力都已经存在，企业为什么还需要一支 Agent 开发团队？
问题在于，这个 Agent 只是完成了一次任务，还没有承担“本月账目已经正确关闭”这个业务结果。
本文的财务对账流程是一个合成案例，用来归纳企业 Agent 常见的生产问题，并不对应某一家公司的真实系统。
能完成任务，不等于能承担业务结果
把刚才的 Demo 接进生产环境，一组新的问题会立即出现：
- Agent 判断两条流水应该匹配，但谁允许它回写 ERP？
- 回写请求超时后，重试会不会造成重复入账？
- 财务经理一天后才批准，运行中的任务如何暂停和恢复？
- ERP 返回成功，但总账余额仍然不平，流程算完成了吗？
- 模型、Prompt 或 Skill 更新后，历史异常案例会不会退化？
- 流水摘要里包含恶意指令时，Agent 会不会误用高权限工具？
这些问题并不主要考验模型能否生成更好的答案，而是在考验系统能否管理状态、副作用、权限和证据。
通用 Agent 的成功通常意味着：它完成了用户当前交给它的任务。企业业务 Agent 的成功则意味着：它把业务流程推进到一个经过验证、可以审计的终态。
通用 Agent
→ “我已经完成了对账分析”
企业业务系统
→ ERP 已产生预期记录
→ 借贷余额通过检查
→ 没有重复入账
→ 所有异常均已处理或升级
→ 审批链和证据完整
两者并不冲突，但责任边界完全不同。Claude Code、Codex 和 Agent SDK 可以成为业务系统里的推理与执行组件，却不能替企业定义什么叫“账已经正确关掉”。
“为什么不能使用通用 Agent”是一个错误命题
企业 Agent 并不一定需要从头开发。
Anthropic 在 Building Effective Agents 中区分了 Workflow 和 Agent：Workflow 通过预先定义的代码路径编排模型与工具，Agent 则让模型动态决定过程和工具使用。对于边界清晰的任务，简单、可组合、可预测的 Workflow 往往是更稳妥的起点。
与此同时，通用 Agent 的基础设施正在快速商品化：
- Claude Agent SDK 复用了 Claude Code 的 Agent Loop、工具执行、上下文管理和子 Agent 能力。
- OpenAI Agents SDK 已经提供 Agent Loop、函数工具、MCP、Session、Guardrail、人工审批和 Trace。
- Codex SDK 可以把 Codex 作为可编程的工程执行单元嵌入工作流。
- Claude Managed Agents 进一步覆盖持久会话、沙箱、凭证、可观测性和扩缩容等生产基础设施。
因此，如果文章把企业自建的理由归结为“通用 Agent 没有状态、权限、审批或沙箱”，结论很快就会过时。平台厂商会不断补齐这些通用机制。
更接近现实的组合是：
购买模型能力
+ 复用通用 Harness 或 Agent SDK
+ 自建企业业务控制层
+ 自建业务结果评测
企业通常不需要再造一个 Claude Code 或 Codex。它真正需要拥有的，是通用 Agent 无法替企业决定的业务语义和责任边界。
Skill 能教会 Agent 做事，但不能成为授权系统
Anthropic 对 Skills 的定义 很清楚：Skill 是包含指令、脚本和资源的目录，用来向 Agent 提供可复用的专业知识；MCP 负责把 Agent 连接到数据和工具。
放到财务对账中，Skill 很适合保存：
- 对账 SOP；
- 拆单、合单和跨期到账的判断方法；
- 异常说明模板；
- 查询顺序和证据要求；
- 生成工作底稿的脚本。
但 Skill 不应该成为以下规则的唯一载体：
- 超过多少金额必须由谁审批；
- 哪些法人实体允许自动回写；
- 同一笔流水是否已经处理；
- 当前操作者能否代表这个租户行动；
- ERP 写入失败后能否安全重试；
- 什么条件满足时流程才能关闭。
这些规则即使写进 Skill，仍然只是提供给模型的自然语言上下文。模型可能误解、遗漏，也可能受到其他输入影响。
硬规则应由 Prompt 外部的 Policy、工具权限和 Validator 强制执行。如果一个团队把这些约束都做进 MCP Server、API 网关或审批服务，那么它实际上已经开始自建企业业务控制层，而不再只是“写了一个 Skill”。
对账 Agent 如何从 Demo 走向生产
一个现实的实现路径，不是先设计复杂的多 Agent 架构，而是让每个生产问题推动一层确定性能力进入系统。
第一阶段：用通用 Agent 验证任务
最初可以继续使用 Claude Code 或 Codex：
财务人员启动任务
→ Agent 读取导出文件
→ Skill 提供公司 SOP
→ 脚本执行精确匹配
→ Agent 分析剩余异常
→ 人工审核并手动回写
这个阶段不要急于追求无人值守。它的价值是验证：
- 模型能否理解真实财务材料；
- 哪些步骤可以用确定性代码解决；
- 哪些异常确实需要语言推理；
- Agent 需要哪些领域工具；
- 财务人员会在哪些地方修改结果。
此时最重要的产物不是 Agent 代码，而是正常案例、异常案例、失败轨迹和人工修正记录。它们之后会成为企业自己的 Eval 数据。
第二阶段：让状态机拥有业务流程
当任务需要跨系统、跨时间持续运行时，不能只依赖一次 Agent Session。业务状态应保存到确定性的工作流或状态机中：
INGESTED
→ NORMALIZED
→ EXACT_MATCHED / AMBIGUOUS
→ AGENT_PROPOSED
→ POLICY_CHECKED
→ APPROVAL_REQUIRED
→ COMMITTED
→ VERIFIED
→ CLOSED / MANUAL_REVIEW
状态机决定流程可以从哪里走向哪里，Agent 只在需要处理歧义的节点工作：
if exact_match_exists:
advance_to(POLICY_CHECKED)
else:
proposal = AgentNode.analyze(available_evidence)
save(proposal)
advance_to(AGENT_PROPOSED)
这里最重要的设计原则是：
Agent 处理歧义，状态机推进业务，确定性服务改变真实世界。
Agent 可以建议下一步，但不能通过输出一句“处理完成”直接改变业务状态。
第三阶段：把真实操作封装为领域工具
Agent 不应该直接获得数据库管理员权限，也不应该把浏览器自动化当作首选集成方式。更稳妥的做法是提供一组范围狭窄、语义明确的领域工具：
get_bank_entries(...)
get_ledger_entries(...)
search_invoice(...)
propose_reconciliation(...)
commit_reconciliation(...)
verify_ledger_balance(...)
写操作的 Tool Contract 至少要表达：
actor 谁在发起操作
tenant 代表哪个组织行动
resource_scope 可以修改哪些资源
expected_version 基于哪个数据版本写入
idempotency_key 如何避免重复副作用
preconditions 执行前必须满足什么条件
evidence 操作依据和返回证据
系统集成可以遵循一个保守的优先级：
领域 API
> 受控数据库或文件接口
> 浏览器 / RPA 适配器
> 人工处理
浏览器自动化有时是接入遗留系统的唯一方式，但它应该被视为受限适配器，并使用更严格的验证和审批，而不是让 Agent 以“像人一样点击”为理由绕过系统合同。
第四阶段：用 Policy 和 Approval 管理风险
企业通常不需要在“全人工”和“全自动”之间二选一，而是根据风险逐步开放自治：
低风险 + 高置信度 + 可逆
→ 自动执行
高金额 / 跨期 / 拆单合单
→ 人工审批
证据缺失 / 规则冲突 / 未知对象
→ 阻断并升级
Agent 可以输出置信度、匹配理由和风险信号，但最终是否需要审批，应由确定性 Policy 计算。否则 Agent 既提出操作，又自行决定是否需要监督，权限边界就失去了意义。
审批也不只是界面上的一个“同意”按钮。系统需要持久保存待审批状态、审批版本和上下文；在审批完成后，恢复原来的 Workflow，而不是重新让模型从头猜测任务进度。
第五阶段：用 Validator 定义业务终态
工具返回成功不代表业务已经正确完成。对账写入后，Validator 还需要独立检查：
- ERP 是否存在预期记录；
- 借贷是否平衡；
- 是否出现重复写入；
- 是否遗漏必须处理的异常；
- 审批人与操作人是否满足规则；
- 输入、建议、审批和结果证据是否完整。
只有这些验证全部通过，状态机才能进入 CLOSED。验证失败时，流程应进入补偿、重试或人工处理状态。
这构成了企业 Agent 与通用任务 Agent 最关键的边界：
Agent 的回答不是业务事实；外部系统经过验证的状态才是业务事实。
第六阶段：用 Eval 管理每一次变化
传统的准确率只能回答“模型是否匹配对了”，但生产 Agent 的失败可能发生在整条轨迹上。Anthropic 在 Demystifying Evals for AI Agents 中也强调，多轮 Agent 会调用工具、改变环境并根据中间结果调整行为，因此评测需要覆盖过程和最终环境状态。
一个对账 Eval 集应同时包含：
- 正常一对一匹配；
- 拆单和合单；
- 跨期到账；
- 手续费与汇率差异；
- 重复流水；
- 缺失单据；
- 工具超时和安全重试；
- 流水摘要中的提示注入；
- 人工拒绝后的恢复；
- 模型、Prompt 和 Skill 升级后的历史回归。
指标也应分成三层：
| 层次 | 示例 |
|---|---|
| 模型过程指标 | 分类、匹配、解释和工具选择准确率 |
| 系统运行指标 | 策略违规、恢复成功率、延迟、成本 |
| 业务结果指标 | 错账、漏账、重复入账、自动关闭率、人工纠正率 |
模型准确率是过程指标，业务终态才是主要验收条件，节省的处理时间和运营成本则是更下游的商业指标。
企业真正积累的也不是一套永远不变的 Prompt，而是一套持续增长的失败样本、业务判断和结果评测。模型可以更换，Harness 可以升级，这套 Eval 仍然能够告诉团队系统是否真的变好了。
Agent 工程师实际在开发什么
招聘需求也能反向说明这个问题。
Hercules 的 AI Context & Harness Engineer 将工作重点放在 Agent Harness、上下文管理、在线与离线 Eval，以及成本、速度和准确率上。Nomic 的 Harness Engineer 则强调检索、上下文组装、评测基础设施、Agent Pipeline，以及在大量真实文档上的规模化。
这些职责可以归纳成五类工程工作：
- Context：检索、压缩、记忆和上下文组装。
- Harness：工具调度、状态、隔离和失败恢复。
- Integration：领域系统、数据合同和安全动作。
- Evaluation：离线回归、在线指标和人工反馈闭环。
- Operations：成本、延迟、可观测性和规模化。
所谓 Agent/Harness Engineer，本质上仍然是一名系统工程师，只是系统里加入了一个能力很强但输出不完全确定的软件组件。Prompt Engineering 是其中一项工作，却不是整个岗位。
Claude Code + Skill、SDK，还是自建 Agent
三种实现方式不是互斥的技术阵营，而是不同阶段和责任范围。
| 场景 | 推荐方式 |
|---|---|
| 低频、探索性、由专业人员监督，主要产出文档或建议 | Claude Code/Codex + Skill |
| 重复任务，但真实操作前仍由人审核 | 通用 Agent + Skill + 领域工具 |
| 需要嵌入产品、保存业务状态、服务多个用户 | Agent SDK + 企业业务控制层 |
| 执行高风险写操作并对业务终态负责 | SDK + Workflow + Policy + Approval + Validator + Eval |
| 流程高度标准化，并非企业竞争优势 | 优先购买垂直 Agent 产品 |
| Harness 本身就是产品，且 Eval 证明现有方案是瓶颈 | 才考虑深度自研 Agent Runtime |
使用 Agent SDK 本身也是一种自建，只是没有重写通用 Agent Loop。企业仍然拥有产品身份、业务状态、领域工具、策略、验证和 Eval。
相反，如果一个团队只编写了 Prompt 和 Skill，并让员工在 Claude Code 或 Codex 里交互使用，它更接近企业定制的通用 Agent 工作流，而不是独立的业务 Agent 产品。这并不低级，反而往往是最合理的第一步。
哪些理由不足以支持自建
企业也很容易高估自己的特殊性。
“数据敏感”并不自动意味着必须自建 Agent。托管产品可能提供私有网络、凭证隔离、审计和自托管执行环境。问题应该是现有方案能否满足具体的数据边界，而不是数据是否敏感。
“我们的业务有特殊规则”也不充分。规则如果只是一些稳定 SOP，Skill、配置和垂直产品可能已经足够。只有当这些规则需要进入实时决策、权限、写操作和结果验证时，自建控制层的价值才开始出现。
“需要多 Agent”更不是自建理由。多个 Agent 会增加协调、延迟和评测难度。如果一个状态机加一个 Agent Node 已经能解决问题，多 Agent 只是额外复杂度。
“希望避免供应商锁定”也要具体分析。抽象所有模型、工具和 Harness 可能制造一个最低公分母平台，却没有带来业务价值。相比统一所有供应商接口，优先稳定企业自己的 Tool Contract、业务状态和 Eval，通常更有迁移价值。
一条更现实的落地路线
企业不需要在第一天决定最终架构，可以让责任范围随着证据逐步扩大：
- 使用 Claude Code 或 Codex + Skill 处理低风险真实任务。
- 保存执行轨迹、异常和人工修改。
- 将重复知识沉淀进 Skill。
- 将真实操作封装成狭窄的领域工具。
- 将硬规则从 Prompt 移入 Policy 和 Validator。
- 建立以业务终态为中心的 Eval。
- 使用 Agent SDK 嵌入产品身份、业务状态和用户体验。
- 根据风险、可逆性和 Eval 结果逐步开放自动执行。
- 只有 Eval 证明通用 Harness 是瓶颈时，才替换对应的 Runtime 层。
这条路线的好处是，每一次自建都有明确证据支持。团队不是因为 Agent 概念很热而扩张系统，而是因为真实任务已经暴露了下一层需要承担的责任。
企业最终需要拥有的是什么
Claude Code、Codex、Skills、MCP 和 Agent SDK 会继续变强。今天需要企业自己维护的部分，明天可能成为平台能力。因此，把竞争力建立在某个暂时缺失的基础功能上并不可靠。
企业需要长期拥有的，是更稳定的几样东西：
- 对业务状态和终态的定义；
- 对真实系统动作的授权边界；
- 领域工具和数据合同；
- 企业独有的异常案例；
- 能验证每次变化的业务 Eval；
- 从人工修正回到系统改进的反馈闭环。
所以，Agent 开发并不是重新开发一个 Claude Code 或 Codex，而是开发一个能让通用 Agent 在企业规则内承担业务责任的系统。
模型能力会快速商品化，Harness 能力也会不断下沉。企业真正需要长期拥有的，是对业务状态、行动权限和正确结果的定义权。