主题
结语 · 从 pixiu 看 agent 工程的边界
这本书讲完了什么
我们从 pixiu 这个 A 股投资工作台出发，走了一遍 agent 工程的全图景：
- 认知：算判分工是第一刀（第 1 章），prompt/context/harness/loop 四阶各有落点（第 2 章）
- 设计：工具按信息密度分层（第 3 章），工具描述是给模型看的 prompt（第 4 章），上下文要主动管理视野（第 5 章），循环要简单、复杂度下沉（第 6 章）
- 验证：非确定性要用统计分层对付（第 7 章），eval 驱动开发能抓退化（第 8 章），打分手段有明确的边界（第 9 章）
- 协作：定时编排与对话自决分工（第 10 章），记忆是会话的蓄水池（第 11 章）
- 工程：错误分四层、连续失败要熔断（第 12 章），双引擎/CI/空壳识别这些底线保命（第 13 章）
- 元层：你和 AI 的协作本身在沿驾驭曲线演进（第 14 章）
每一个结论，都不是凭空想的，都长在 pixiu 的真实代码、真实实验、真实踩坑上——你可以打开 pixiu 源码，按每章的"pixiu 锚点"逐一验证。
agent 工程不是新学科，是软件工程换了约束
写到这，我想戳破一个迷思。很多人把"agent 工程"当成一个全新的、神秘的学科，觉得得从头学一套不知道什么东西。
pixiu 的经验恰恰相反：agent 工程不是新学科，是软件工程换了一批新约束。
你看这本书里的内容——
- 接口设计，换成了"工具描述是 prompt"（你的 API 设计功底全用得上）
- 错误处理，换成了"四层分流 + 熔断"（你的异常处理功底全用得上）
- 测试，换成了"eval + 统计"（你的 TDD 功底全用得上）
- 流程编排，换成了"pipeline + 自决循环"（你的架构功底全用得上）
- 状态管理，换成了"上下文分层 + 记忆闭环"（你的数据流功底全用得上）
约束变了：从"确定性"变成了"非确定性"，从"二元对错"变成了"概率分布"，从"函数调用"变成了"模型决策"。但底层的工程素养——分层、抽象、护栏、可观测、可测试、韧性——一个没变，全是你熟悉的那些。
所以传统程序员做 agent，别慌。你的主场没丢，只是多了几个新旋钮。把这几个新旋钮（非确定性、上下文窗口、工具描述、模型决策）摸熟，剩下的还是你那一套。
pixiu 还没解决的问题（诚实交代）
我不想把 pixiu 写成一个"完美产品"。它有很多我暂缓处理的问题，这些同样是 agent 工程真实的一部分。诚实交代几个：
- Tushare SDK 没有 timeout。 这是第三方 SDK 的限制，pixiu 的 R1 工厂解决不了——SDK 内部行为不可控，可能挂起（findings R1-5）。
- 数据源错误静默返回空。 Tushare 的 provider 出错时常返回空 DataFrame，调用方分不清"真没数据"还是"调用失败"。改成抛异常会破坏所有调用方"空=无数据"的契约，是 API 级改造，收益有限，暂缓（R1-4）。
- 概念板块功能受限。
sync_concepts调的 Tushareths_index接口，当前套餐没权限。不是代码 bug，是数据源套餐限制（W4-1）。 - moneyflow 数据偶发滞后。 自动刷新没跟上 Tushare 的发布节奏，偶发落后几天。根因需要生产环境日志确诊，本地改不了（W2-2）。
- 探索漏斗常出 0 卡片。 三层漏斗阈值叠加，强市场日筛不出标的。机制完整，属调参/市场问题（W4-2）。
- 同模型裁判的自评偏差未充分验证。 E2 实验用手写叙事验证了裁判准确，但"agent 生成 + 不同模型裁判"的对比因没配第二个模型而受限（E2）。
这些问题我都没装作不存在。它们说明——agent 工程永远有边界外的约束（第三方 SDK、数据源权限、生产可观测性），你能做的是把边界内的做扎实，边界外的诚实标注、择机处理。这份诚实，本身就是工程严谨的一部分。
最后
回到引言里那个"遗憾"——上一本手记道理对，但案例没长在一个具体项目上。
这本补上了。书里的每一个观点，都长在 pixiu 上；每一个代码引用，你都能在源码里找到；每一个量化结论（ruff 415→0、eval 20%→100%、CI 83 passed），都有实验撑着。
如果你也在做 agent，希望这本书能让你少踩几个坑。当你踩到某个坑时，如果能想起"pixiu 这里也栽过"，然后少疼一点——这本书就算没白写。
pixiu 还在演进，我的手记也还会继续记。这不是圣经，是一个工程师一路走、一路标的记号。你要是也在走这条路，这些记号也许能帮上忙。
走吧。