<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AI on Yu's Space</title><link>https://code-agree.github.io/tags/ai/</link><description>Recent content in AI on Yu's Space</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Mon, 27 Jul 2026 11:56:41 +0800</lastBuildDate><atom:link href="https://code-agree.github.io/tags/ai/index.xml" rel="self" type="application/rss+xml"/><item><title>Optiver 的 Agentic SDLC：围绕 AI Agent 重新设计开发流程</title><link>https://code-agree.github.io/blog/2026-07-27-optiver-agentic-sdlc/</link><pubDate>Mon, 27 Jul 2026 11:56:41 +0800</pubDate><guid>https://code-agree.github.io/blog/2026-07-27-optiver-agentic-sdlc/</guid><description>本文是对 Optiver 技术博客 Engineering the Agentic SDLC（2026-06-23）的阅读整理与延伸思考。Optiver 是全球顶级做市商，这篇文章记录了他们把 AI Agent 纳入交易系统开发流程的实验，压力测试场景是 HFT 工程里最&amp;quot;脏&amp;quot;的活之一：接入新交易所。
核心命题 #不要把 Agent 塞进为人类设计的开发流程（SDLC）里去加速旧流程，而是从零开始围绕 Agent 重新设计开发生命周期。新前提是：Agent 承担大部分工作，人类负责引导和把关。由此几乎一切都要变——规格说明、工具链、代码评审、可观测性、甚至代码组织方式。
Optiver 的判断很清醒：具体工具未必长久，但底层约束比工具本身更耐久。
他们把这套体系拆成三层：
SDLC 工作流：开发、评审、测试、发布、运维。 Agent 原语：上下文（context）、执行环境（harness）。 共享底座：度量、执行、编排、治理。 压力测试：接入新交易所 #测试场景选得很有代表性——交易所连接。每个交易所都需要一个会话管理组件（登录、心跳、与内部系统通信），工作重复但细节因场所而异，小的协议差异出错代价很高，而且每接一个新交易所都要重来一遍。
结果：上线时间缩短 75%，工程人力投入减少 85%，约 90% 的产出达到&amp;quot;可直接送审&amp;quot;质量。
早期尝试很粗糙：通用编码 Agent 只能做到一半——不理解组件、无法可靠驱动测试工具、看不到系统内部关键部分、无法判断自己的代码错了，于是用各种&amp;quot;变通方案&amp;quot;填坑，这些代码根本过不了评审。他们的关键发现是：大多数失败源于外围工作流的缺口，而不是模型本身。
四条核心经验 #1. 黄金路径是工程出来的 #想要端到端可用的 Agent 流水线，必须通过工程手段压低方差，不能靠运气。每一步要么是显而易见的下一步，要么被明确文档化为下一步——不能指望 Agent 自己悟出来。他们为此做了三件事：重写组件、去掉会变成运行时错误的静默默认值；收紧规格、让操作顺序无歧义；构建编排框架，让 Agent 分阶段推进、阶段之间设验证门、每阶段只注入当前相关的上下文。
2. 上下文决定结果 #AGENTS.md 不是上下文的全部。Agent 需要三类上下文，缺任何一类都会产生不同的失败模式：
系统上下文：组件做什么、约束是什么。 领域上下文：外部环境实际如何表现——从真实流量中捕获。 方法上下文：这类问题怎么解、怎么测、什么算好。 领域上下文最有意思：交易所文档只告诉你有哪些报文，不告诉你发出去之后会发生什么。让 Agent 能探测线上系统、捕获真实流量的工具，把 Agent 锚定在现实上，而不是锚定在推断上。做过交易所对接的人对这句话应该都有生理反应——文档和真实行为之间的 gap 才是工作量的大头。
3. 反压（Backpressure）降低方差 #Agent 会在没成功的时候告诉你它成功了。解法是把&amp;quot;是否成功&amp;quot;的判定权从它手里拿走：用真实捕获流量构建应用测试；支持在非生产环境跑端到端场景、拿到干净的通过/失败信号；编排框架用代码验证每阶段交付物。
最终形态：Agent 在创造性部分（协议理解、实现、边界情况）自由发挥，在确定性部分（编译过没有、测试过没有、场景跑通没有）被严格约束。缺少反压，错误、bug 和坏设计会随着 Agent 独立工作不断复利放大。</description></item><item><title>Prompt manager</title><link>https://code-agree.github.io/projects/first/</link><pubDate>Sat, 03 Aug 2024 00:00:00 +0800</pubDate><guid>https://code-agree.github.io/projects/first/</guid><description>project description #Prompt Manager is a Chrome extension designed to help users save, manage, and quickly access frequently used prompts. It&amp;rsquo;s perfect for writers, customer service representatives, or anyone who often uses repetitive text snippets in their daily work.
Main features #Save and manage text prompts Search through saved prompts Sort prompts by time or custom order Edit existing prompts Delete prompts One-click copy of prompts Import and export prompts for backup or transfer</description></item></channel></rss>