OpenHands 帮我们省掉哪些代码，又有哪些事仍要自己决定？

OpenHands 帮我们省掉哪些代码，又有哪些事仍要自己决定？

先把库存助手拆回五个零件

第一节的助手反复执行“模型选择动作→工具执行→结果写回历史→模型继续”。若从头实现，除了这个循环，还要处理模型请求格式、工具定义、工作目录、事件存储、上下文长度、错误恢复与人工确认。OpenHands这类框架把许多重复结构组合起来，让开发者围绕任务补充工具和规则。

我们以课程第14讲展示的架构为准理解职责，不把课堂代码截图当作当前版本API手册。框架版本会改变具体类名和调用方式，但仍可问五个稳定问题：谁产生动作，谁声明工具，谁运行工具，谁记录会话，谁隔离工作环境？搞清这些，比记住一段构造函数更有迁移价值。

用户要求“读取库存CSV，生成补货建议”。模型组件接收任务、可用工具与历史；工具定义告诉它可以调用读取、计算、写文件；模型输出结构化Action。执行器校验参数，在指定Workspace里运行，返回Observation。Conversation把动作与结果纳入事件流，决定是否继续调用模型或结束。

注意Action是请求，Observation才是执行反馈。模型生成 write_file 不等于文件已经写入；执行器可能报路径错误、权限拒绝或磁盘失败。会话必须把这些结果交还给模型，而不是只存一段“助手说已保存”。最终成功由独立文件检查决定，不能仅由循环停止决定。

模型适配层可减少不同供应方请求格式差异；工具注册可统一schema与结果包装；会话层可保存事件、支持恢复；上下文处理可在历史过长时摘要；执行环境可管理本地或远程工作目录；确认机制可让高影响动作进入等待状态。这些能力减少胶水代码，也使观测与调试位置更集中。

但“有确认机制”不等于所有危险动作都会自动确认。谁标记需确认、展示哪些参数、批准绑定哪次请求、拒绝后如何继续，都要设计。同样，有上下文摘要不等于关键约束不会丢失；有持久化不等于外部服务副作用可以安全重放。

观察过程 · 改变条件

先预测结果，再逐步查看；切换条件时留意是哪一个中间量改变。案例是教学构造的规则回放，不是模型训练实测。

教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。

这一轮的输入

读取CSV并生成补货建议

模型与工具

模型选择读取、计算、写文件等领域工具。

1 / 3

先预测，再核对结果与原因

框架管理循环，领域规则判断结果。

基础连接可复用，任务成功标准需要明确实现。

把库存CSV换成代码仓库，目标改为修复一个解析错误。模型与会话循环仍可复用；工具从读表、写建议换成搜索代码、编辑文件、运行测试；Workspace从数据目录变为隔离checkout。成功标准从逐SKU核算变为特定失败用例修复、相关回归通过和差异可审查。

第一个条件变化是工具能力扩大：shell或浏览器比单一只读查表更灵活，也可能接触更多资源。需要重新设置文件、网络与凭据边界。第二个变化是任务完成证据：测试进程退出0不一定覆盖目标bug，还要确认测试断言、执行版本和改动范围。框架复用不会替你完成这些领域判断。

框架支持专门角色时，可以把复现、定位、修改、验证分开，提升职责可见性；但角色更多也带来消息传递、共享状态和错误相互传播。两个角色都使用同一错误测试，互相同意不构成独立证据。外部工具协议统一了接入方式，也不等于统一了授权与信任级别。

开始构建时可以先用一个简单任务贯穿完整闭环：输入文件固定、一个工具可失败、产物能独立核验、事件可回放。看清Action到Observation和结果验证后，再扩充复杂角色。这样得到的是可解释系统，而不是多个组件名称堆在一起。

本课的交付判断是：能指出框架替你维护的状态，以及你仍负责的工具语义、权限、评价与运行预算。下一课挑出持久化最容易误解的部分：进程断了，事件日志还在，就能从最后一行直接继续吗？

问题 1

模型发出写文件Action就算保存成功吗？

展开解释

不算。必须看执行器Observation和真实文件检查，Action只是请求，可能执行失败。

问题 2

框架提供确认接口为何仍要设计权限？

展开解释

接口只是机制，哪些动作需要确认、批准范围和拒绝行为都取决于任务策略；工具仍需实际授权检查。

问题 3

两名Agent都说测试通过就算独立验证吗？

展开解释

不一定。若共享同一错误测试或未核对执行版本，结论可能一起错。独立性来自证据来源和检查设计，而非角色数量。