一篇来自掘金的技术文章以一次真实问答为样本：用户询问Java并发容器ConcurrentHashMap的读写并发原理，系统从收到请求到给出完整答案用了46秒。服务端日志显示，这不是单次模型调用，而是3轮推理、4次知识库检索接力完成。文章将过程拆开，展示ReAct机制如何影响上下文长度、工具调用、延迟和token消耗。
单轮推理：输入先被整体读取，输出再逐字生成
文章把单次推理拆成一条流水线：输入全量重发，模型先进行prefill，再进入decode。prefill阶段一次性并行读取全部输入，计算Key/Value向量，并写入KV Cache；decode阶段则按自回归方式逐字生成，速度受输出长度影响。实测中，一个只发送“你好”的新会话输入达到12,212个token，问题本身只有2个token，其余12,210个来自模型运行所需的底座。
该模型的prefill速度约为7,000 token/s，12K底座约需1.7秒；decode速度约为105 token/s。文章将单轮耗时概括为排队、prefill和decode三部分。ConcurrentHashMap案例第3轮达到25.2秒，并非检索最重，而是这一轮要输出4,182字答案，decode占据了大部分时间。输出量决定decode时间，成为慢问归因时需要优先查看的位置。
三轮ReAct：模型自己发现盲区，再决定是否继续检索
这次案例的关键，在于ReAct循环如何自主推进。第1幕用5.1秒进行宽面撒网，thinking块为779字，模型同时发起两路检索。第2幕用9.3秒定向补漏，thinking块为303字，模型发现get无锁、volatile与JDK7分段锁对比、弱一致性迭代器等材料仍未覆盖，于是再次发起检索。第3幕用25.2秒收网成文，thinking块为321字，模型判断材料足够，不再调用工具，直接输出4,182字答案。
文章强调，多轮推理不是开发者预先写死的流程。模型读取第一轮检索结果后，自己发现知识盲区，并把缺口转化为新的检索动作。每一次工具返回都会成为新的证据，模型再据此修正判断。ReAct的特点正在于此：推理和行动交替进行，模型看一步、想一步，再决定是否继续查。
上下文和工具是Agent的隐性账单
围绕上下文，文章指出大模型本身无状态，记忆依赖外部系统把历史对话重新写入输入。随着轮次增加，案卷不断变厚，ConcurrentHashMap案例的输入从13.9K增长到20.2K。虽然轮内KV Cache可以减少重复读取，但跨轮前缀缓存实测为cachedTokens=0，意味着每一轮仍重新prefill，这也是文章列出的优化点。
工具描述和记忆文件同样构成固定开销。系统内置22个工具，schema约5,000 token，每轮随请求重发；3轮案例中，这部分框架开销约15,000 token，比问题本身和检索回来的知识都更贵。MEMORY.md记忆文件为15,404字符，约合5,200 token，占底座42.6%。system prompt总长为19,512字符，由自写系统提示词1,400、MEMORY.md 15,404和harness框架指令约2,708组成。由于记忆会持续膨胀，它成为比工具更长期的治理课题。
从一次实测看Agent工程取舍
文章还把ReAct放进更大的Agent架构版图中。长思考属于模型层能力，而ReAct、先规划后执行、图状态机、主控派活、辩论与裁判等属于编排层方案。它们并非互相替代，而是可以叠加。生产系统通常按任务选择档位：需要确定性时，更靠近写死流程或图状态机；需要协作、分解和上下文隔离时，更靠近多agent方案；需要人进入流程把关时，图状态机更容易承接。
ReAct的优势是行为更接近自主决策，但代价是不确定性：轮数难以预测，执行轨迹不易复现，慢请求归因也更复杂。这次实测的价值，不只是解释一次问答为什么用了46秒，而是把Agent系统的隐性成本拆开：上下文增长、工具描述、缓存命中、输出长度，都会直接影响最终体验和token账单。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dang-ai-jue-ding-zai-cha-yi-ci-yi-ci-react-tui-li-bei-hou
