模型能力会升级；身份、权限、业务规则、状态与故障恢复，仍需要被认真设计和验证。
补丁会折旧，系统仍需建设
传统开发的抽象与架构经常可以长期复用。Agent 开发却有一种不稳定的触感：今天写下的大量解析、路由和规划逻辑，下一代模型可能原生就能完成。
真正值得区分的，是为当前模型缺陷打补丁，与把模型接入真实业务系统。
前一类工作可能随着模型升级而缩减；后一类工作的目标，是让模型的建议经过明确规则，成为可授权、可验证、可恢复的行动。这个划分是分析工程价值的视角，不是所有岗位的未来时间表。
本文从所提供的 Bilibili 视频学习笔记重组而来；视频转述、个人判断与补充工程资料，在文中分别说明。
模型能力边界与业务系统边界
两类工作都可能表现为“加校验、加重试”，但它们要解决的问题不同。
| 维度 | 模型能力边界 | 业务系统边界 |
|---|---|---|
| 典型问题 | 格式不稳定、工具选择错误、长任务遗忘、规划漂移。 | 身份、权限、事务、数据一致性、审批与审计。 |
| 升级后的变化 | 可能简化，也需要重新评估。 | 规则仍须由业务与执行系统落实。 |
| 重试的例子 | 让模型重新生成合规参数。 | 处理网络超时，并避免重复扣款。 |
“模型能力更强”不意味着所有补丁立刻失效。结构化输出仍要通过业务校验；长上下文仍有成本和信息选择问题；工具调用再准确，也不能替代权限检查。
复查一个模块时，先问：如果明天换成更强的模型，这条规则是否仍然需要？保留有业务意义的约束，评估已经可以删减的能力补偿。
让建议经过规则，才成为行动
语言模型的输出并不提供业务正确性保证。模型可能理解错误、编造信息、选择错误工具或参数。软件系统需要把身份、约束和状态变化写成可检查的规则。
- 01模型理解与推理
- 02生成结构化行动
- 03执行系统校验
- 04授权后调用工具
- 05验证结果与记录状态
订单从 CREATED 到 PAID、SHIPPED、COMPLETED，应由已发生的业务事件推动。模型说“应该已经发货”，不能成为跳过付款与出库检查的理由。
这里的“确定性系统”指关键规则和状态转换被显式实现，不意味着现实世界没有故障，也不意味着程序能绝对保证不出错。LLM 负责提出方案；执行系统负责约束它能做什么，以及怎样确认执行结果。
一笔采购款，需要哪些保证？
假设一个供应链 Agent 判断库存不足，建议向供应商支付 20 万元采购款。自然语言建议可以合理，但它不应直接变成一次付款调用。
- 01身份认证
- 02权限与额度检查
- 03库存及订单核对
- 04业务审批
- 05执行与幂等控制
- 06结果核对与审计
尤其要处理“成功了，但没有收到回执”
付款接口超时，可能意味着请求没有执行，也可能意味着付款成功而响应丢失。盲目重试会带来重复付款风险。
- 给业务操作绑定稳定的幂等标识，并由接收系统落实去重。
- 执行前检查当前订单状态、金额、收款方和审批记录。
- 结果不明确时，查询交易状态、进入待核对状态，必要时交给人处理。
- 留下参数、操作者、批准者、工具响应与最终状态，支持追踪和恢复。
这是一个简化的教学案例，具体事务边界、支付协议与风险阈值仍取决于真实业务。关键在于：把不确定性留在明确的状态中处理。
链路越长，验证越重要
一个有用的数学示意：若每一步成功概率均为 95%，各步独立，而且整个任务要求十步全部成功，则：
0.95¹⁰ ≈ 59.9%
这是简化模型，不是所有 Agent 的实测成功率。真实步骤可能相关，重试、恢复与验证也会改变结果。
因此，不能只画一条 LLM → Tool → LLM 的链，就把它视作可靠系统。重要节点需要验证结果、保存检查点、限制超时与重试，并隔离失败。
- Checkpoint：记录已确认的进展，恢复时不必全部重做。
- Validation：使用真实环境结果核对目标，避免模型自称完成。
- Retry / Fallback：区分可重试与不可重试的失败，设定预算。
- Interrupt / Resume：支持暂停、人工介入与继续执行。
增加 Agent 数量或审查轮数，也会增加成本、延迟和失败入口。复杂度是否值得，应由任务评估决定。
怎样选择更耐用的技能？
下面是学习投资的启发式划分，不是精确的价值排序。某个项目仍可能必须使用专门 Prompt、Router 或复杂 Workflow。
| 层次 | 例子 | 学习重点 |
|---|---|---|
| 随模型变化较快 | 特定 Prompt 技巧、手工 JSON 修复、补偿式规划。 | 理解使用条件，及时复评，避免过度绑定。 |
| 持续演进的 Agent 工程 | Context Engineering、工具设计、Eval、Runtime。 | 用真实任务检验可靠性、成本与维护负担。 |
| 长期软件基础 | 后端、数据库、状态机、分布式系统、安全、可观测性。 | 明确数据、权限、状态变化与故障恢复。 |
框架能帮助实现，但熟练调用某个框架 API，不等于理解执行语义。更稳妥的职业目标是：能够设计、构建和维护 AI Agent 系统的软件工程师。
上下文、工具与评估怎样落地？
Context Engineering：在需要时提供需要的信息
选择相关资料，保留必要状态，检索记忆，压缩历史，筛选工具结果。上下文窗口变大后，也仍要考虑成本、信息相关性与维护。Anthropic 的工程文章提供了一套可参考的实践视角。
Tool Design：动作边界要清晰
把 do_everything() 拆成可理解的动作，例如查客户、读订单、验证订单和退款。输入、输出、权限、错误与副作用要明确。查询与写入的语义不同，重试策略也不同。
Eval：用一组任务，观察一类失败
关注端到端任务成功率、工具调用成功率、事实错误、延迟、成本和失败类型。不要用一次演示代替评估；模型或工具升级后，使用代表性任务重新检查。
评估也应覆盖不该执行的动作：越权是否被拒绝？参数不合法时会怎样？回执丢失后会不会重复执行？这些能力需要测试实际系统边界。
Harness：模型之外的运行环境
可以把 Agent Harness 理解为围绕模型的运行环境：它提供上下文、工具、权限、沙箱、记忆、检查点与观测能力。不同实现对 Harness 和 Runtime 的范围划分不完全一样。
模型提供理解与生成能力；Harness把它连接到任务、工具、状态与约束。
日志与 Trace 应能回答：运行了什么动作，使用了什么参数，工具返回了什么，哪里失败，花了多少时间与成本。记录过程不等于要求模型暴露私有思维链；可观察的操作与结果已经是重要证据。
运行环境还要处理不可信的输入。文档、网页和工具输出可以提供信息，但其中的指令不能自动获得用户授权，也不能绕过执行权限。
持久执行、状态恢复和事件历史有成熟的软件工程积累，Temporal 的 Workflow Execution 文档是一个参考。使用任何平台都仍须理解外部副作用与幂等的边界。
来源与阅读边界
起点是所提供的《为什么我觉得 agent 开发这个工作怪怪的？》中文笔记。原笔记没有视频 URL、作者身份或完整逐字稿，所以本文不将其中的转述作为逐字引文。技能折旧与职业价值属于个人综合判断；以下资料用于补充工程概念，并不替这些预测背书。
- Anthropic · Building effective agents（2024）
Workflow 与 Agent 的区分、工具接口、环境反馈与按需求增加复杂度。
- Anthropic · Effective context engineering for AI agents（2025）
上下文选择、压缩、工具和长任务管理的实践视角。
- Temporal · Workflow Execution overview
持久执行、事件历史与恢复；作为软件系统的参考，而非 Agent 的唯一架构。