深入 PenguinHarness Agent 运行循环审批、并发工具与上下文压缩全解析【免费下载链接】penguin-harness Unified and Stable RSI Platform项目地址: https://gitcode.com/gh_mirrors/pe/penguin-harnessPenguinHarness Unified and Stable RSI Platform是一款统一且稳定的 Agent 运行平台。它的核心是一套名为 context_engine 的Agent 运行循环把大模型、工具执行、人工审批、断点续跑和上下文压缩编排成一条可靠的事件流水线。本文用尽量少的代码带你彻底看懂三件事工具审批如何安全可控、多个工具调用如何并发执行、上下文压缩如何在关键时刻为会话瘦身。一张图看懂session.run 驱动的 ReAct 循环整个运行循环只有一个入口session.run(newMessages, opts?)。你在 session.ts 中能看到它接收本次新增的消息Prompt返回一个异步生成器流式产出每一条消息——文本分片、工具调用、工具输出、审批决策、Token 用量……全部实时推给界面同时写入 Trace 文件。一次run会驱动一个完整的Task内部是层层嵌套的循环外层轮次循环模型每返回一批工具调用就构成一轮turn模型给出不再调工具的最终答复时Task 结束轮内重试阶梯单次 LLM 请求失败会自动重连最多 5 次无效重连、每轮至多 20 次尝试期间用指数退避等待且已产生的部分输出会随[turn_retried]标记带回不会重跑工具压缩检查点每轮 LLM 请求产生 Token 用量后引擎都会检查一次是否触发上下文压缩。这个编排全部实现在 context-engine.ts想深入细节的话官方文档 agent-loop.zh.md 是最权威的地图。审批机制逐个审批、并行执行审批是轮内交互某个tool_call的流式传输一完成引擎立刻调用你传入的approve回调类型定义见 interfaces/shared.ts等待决策后再执行。这里有个精妙的设计——环节是否串行为什么审批请求✅ 逐个进行决策必须有序、可审计每次决策都会记录为一条approval_decision事件工具执行 并发进行批准后的工具立即在 Environment 中运行不阻塞后续工具的审批默认行为是保守的不传approve回调时引擎对一切工具调用返回deny。除此之外还有两道防线命令策略Command Policy项目级安全配置运行在审批层之上。被策略标记为forbidden的命令无论审批模式怎么答都保持拒绝实现见 command-policy.tsPre-tool-use 钩子每个工具调用在询问审批之前先咨询钩子hooks/tool-hook.ts钩子可以直接deny或直接allow跳过询问但命令策略的否决权仍然压过它。被拒绝的调用不会让模型卡死引擎会生成一条合成的aborted工具输出如 Tool call denied by user.喂回给模型让它据此调整方案继续。并发工具执行MergeQueue 如何合并多路流一轮里模型可能同时发起 N 个工具调用。引擎用 merge-queue.ts 中的MergeQueue把LLM 事件流 N 个并发工具输出流合并成一条yield 序列。顺序规则值得记住流出顺序 完成顺序哪个工具先跑完它的tool_call_output就先推给前端用户实时看到进度回传顺序 原始调用顺序整批工具全部到达终态后结果会按模型最初发起调用的顺序重排再作为下一轮输入——保证反馈顺序与调用顺序严格一致。还有一条重要时序LLM 流结束时的token_usagerequest_end不等待工具发出也就是说仍在执行的工具输出可以出现在request_end之后——前端和 Trace 都能如实呈现这种请求已收、工具还在跑的状态。上下文压缩summarize 与 discard 双模式长会话最大的敌人是上下文窗口。PenguinHarness 的压缩配置CompactionSettings由四个要素组成配置项作用maxContextLength上下文 Token 阈值基于最近一次请求的request.total判断maxSessionTurns会话累计轮次阈值跨 Task 计数-1 为不限modesummarize总结或discard丢弃prompt总结时使用的压缩 Promptsummarize把对话浓缩成摘要这是默认模式。触发后引擎在当前 LLM 对象上追加一条压缩 Prompt 发出一次普通的压缩请求summarizeContext成功则旧上下文关闭通过openNextContext打开全新的模型上下文摘要成为新上下文的第一条输入Trace 文件同步轮转rotate新文件自带session_meta自包含、可独立重放压缩发生在 Task 中途时摘要直接成为新上下文的首条输入模型靠摘要里自己写下的下一步计划继续无需硬编码的续跑指令。压缩失败可重试/致命时引擎保留原上下文摘要留待下一次触发补做绝不降级为直接丢弃。discard直接换新上下文discard模式不做总结请求直接丢弃当前上下文。为避免掐断进行中的 Task引擎会先等到 Task 真正结束才执行。手动压缩与模型切换用户可随时发起/compact引擎在压缩前先检查 compactability——未配置、当前上下文一轮都没跑完、或刚压缩过都会提前给出明确反馈避免 UI 无限等待切换模型 强制 summarizeswitchContext 会先用摘要收尾旧上下文再在新模型上打开新上下文——旧模型的会话由摘要无缝交接给新模型。中断不丢消息carry-over 与自动重连运行循环的稳定二字一半来自中断处理。用户随时可以Ctrl-C/ 点击停止引擎按这一轮进行到哪一步生成补发内容模型输出已完成tool_call 已提交→ 已完成的工具结果原样补发没跑完的调用补占位符保证 tool_call 与输出严格配对模型输出未完成 → 整轮压平成一段[turn_aborted]用户文本携带已产生的部分输出。补发内容只进入模型上下文、不写入 TraceTrace 永远只记录真实发生的消息下次run时自动拼在新消息前面。LLM 流式断连也走同一套重试阶梯配合重试绝不污染历史的提交规则做到断线重连后不重复、不遗漏。在 Web 界面观察这些机制所有机制都不是黑盒。PenguinHarness 的 Web 端把运行循环全程可视化审批弹窗与决策记录、并发工具的实时输出、压缩横幅含尝试次数与状态、Trace 轮转文件都能在界面上直接看到。下面的评估中心截图展示了运行数据如何被汇总呈现延伸阅读 运行循环总览agent-loop.zh.md源码级逐步拆解含完整流程图 引擎实现context-engine.ts 会话与运行入口session.ts、agent.ts 多路流合并merge-queue.ts 命令策略command-policy.ts✂️ 压缩默认值与 Token 上限context-limits.ts 钩子体系hooks/stop / pre_tool_use / user_prompt 三个钩子点一句话总结PenguinHarness 的 Agent 运行循环 「一个 run 驱动完整 Task」「逐个审批、并发执行」「每轮检查点的上下文压缩」「永不丢消息的中断续跑」。理解这四条主线你就掌握了它稳定的全部秘密。【免费下载链接】penguin-harness Unified and Stable RSI Platform项目地址: https://gitcode.com/gh_mirrors/pe/penguin-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考