恒生电子二面：DeepSeek Harness、插件化与 MySQL 日志

《面试题目》

1. 自我介绍。
2. 实习产出的细节，以及某些优化是否可行？
3. 介绍一下 DeepSeek Harness，它和别的 Agent 有什么不同？
4. “一切皆插件”底层是怎么实现的？
5. 讲一些 SQL 优化的方法。
6. 索引失效的场景有哪些？
7. MySQL 的三大日志分别是什么？职责是什么？
8. InnoDB 和 MyISAM 有什么区别？
9. 怎么提升 AI Coding 的准确率和效率？

《参考解析》

Harness 类 Agent 的差异：普通聊天式 Agent 往往把“模型 + 工具”直接暴露给用户，Harness 更强调一层受控执行框架：统一管理上下文、工具调用、权限、重试、日志、评测和回放，让行为可复现、可审计。差异可以落在四点：执行有状态（任务、步骤、检查点）、工具有边界（白名单、参数校验、超时）、过程可观测（trace、token、耗时）、结果可评测（回放集、回归）。如果面试官追问具体实现，就讲调度循环、工具注册表、上下文装配和错误处理。

一切皆插件：核心是“接口 + 注册表 + 生命周期”。定义统一的插件接口（初始化、执行、销毁、健康检查），插件通过配置文件或注册中心声明能力、版本、依赖和权限；主程序启动时扫描/加载插件，运行时按能力路由调用，插件之间通过事件总线或明确的服务接口通信，不直接互相依赖。隔离上可以用独立进程/容器、类加载器或 WASM，避免一个插件崩溃拖垮主程序；升级要支持热加载和版本兼容。难点是依赖管理、权限边界和可观测性，不是“写个 interface 就完了”。

SQL 优化：先用 explain 看执行计划，关注 type（避免 ALL）、key、rows、filtered、Extra（Using filesort、Using temporary）。常见手段：为 where/join/order by 建合适的联合索引并遵循最左前缀；避免 select *，只取需要列；分页深翻用游标或延迟关联；大表按时间分区或归档；批量插入代替逐条；避免在索引列上做函数/类型转换；用覆盖索引减少回表；控制事务长度，减少锁竞争。优化后要对比实际耗时和扫描行数，不要只看“走了索引”。

三大日志：redo log 是 InnoDB 的物理日志，记录页的修改，保证崩溃恢复和持久性（WAL）；undo log 是逻辑日志，记录反向操作，用于事务回滚和 MVCC 一致性读；binlog 是 Server 层的逻辑日志，记录语句或行变更，用于主从复制和数据恢复。三者配合：事务提交先写 redo（prepare），再写 binlog，最后 redo commit（两阶段提交），保证崩溃时主库与从库一致。

InnoDB 与 MyISAM：InnoDB 支持事务、行级锁、外键、MVCC、崩溃恢复，聚簇索引组织数据，适合 OLTP；MyISAM 不支持事务，表级锁，索引与数据分离，计数快、压缩表适合只读场景，崩溃后可能需修复。MySQL 5.5 起默认 InnoDB，新项目基本不用 MyISAM。

AI Coding 提效：准确率取决于上下文和验证。做法：把任务拆成小步、给足接口定义/数据样例/错误日志、明确约束（版本、异常处理、不要新依赖）、先写测试再生成实现、要求解释改动、生成后跑 lint/typecheck/单测、对关键路径人工 review。效率上建立常用模板和规则文件，让模型遵循项目风格；不要一次让它改十个文件。