基于
deepseek-ai/deepseek-harness（TypeScript / Cordis 插件总线）与openai/codex（Rust / codex-rs crate 体系）两个成熟开源项目的真实源码整理。 本文把每层的关键数据结构、控制流、不变量讲清楚，并为每个核心模块附上实现逻辑——这些是写 Agent 时真正会踩坑的地方。 所有代码路径均为实际文件，可下钻核对。伪代码为便于阅读对真实实现做了抽象，但结构与关键分支与源码一致。
0. 先定位：Agent 是什么
Agent = 以 LLM 为决策核心、以 Tool 为手、以 Sandbox 为边界、以 Append-Only 会话日志为记忆的闭环。
两条跨实现的底层信条：
分层总览
基于
deepseek-ai/deepseek-harness（TypeScript / Cordis 插件总线）与openai/codex（Rust / codex-rs crate 体系）两个成熟开源项目的源码与架构文档整理。 目标：用「分层 + 核心模块详解」的方式，把一个 Agent 讲清楚。
0. 先定位：什么是 Agent
一个 Agent 本质上是一个以 LLM 为决策核心、以工具为手、以沙箱为边界、以会话日志为记忆的闭环系统：
无论 TS 还是 Rust 实现，所有 Agent 的模块都收敛到同一组子系统。下面按自底向上的依赖顺序分成 7 层。
分层总览
为进一步提升公司代码安全自动化防护能力，研发中心围绕Strix多智能体网络安全渗透测试工具，针对开源Java漏洞实训平台JavaSecLab开展白盒深度代码审计与系统化渗透测试选型论证。本次评估重点考察Strix在复杂业务逻辑场景下的漏洞挖掘效能、标准化报告输出能力，以及对接CI/CD研发流水线的集成适配潜力，具体论证情况如下：
1. Strix：LLM驱动的多智能体安全审计架构
Strix是基于大语言模型（LLM）构建的自动化渗透测试工具，核心能力为多智能体协同检测。本次测评对象JavaSecLab基于Spring Boot、MyBatis‑Plus、Layui等主流技术栈搭建，Strix可实现源代码、框架配置、业务逻辑、第三方依赖组件的全域覆盖。 借助深度扫描模式，工具完成全量代码静态分析、漏洞溯源与完整数据流审计，成功识别出反序列化RCE、SQL注入、认证绕过、SSRF、XXE等多类型安全漏洞，覆盖代码层、依赖层、业务逻辑层多个风险面。
摘要
大语言模型驱动的代码生成技术正在重构传统软件工程的生产模式，软件开发重心逐步从手工代码编写迁移至需求定义、约束建模与质量验证环节。上海交通大学林云副教授提出 需求编译（Requirement Compilation） 理念，以 ARC（Agentic Requirement Compilation）智能体需求编译框架为核心，探索把大规模多模态业务需求文档直接转化为可运行软件系统的技术路径，同时开展面向智能体软件工程的课程教学改革，推动开发者从“代码工人”向“智能体架构师”转型。本文基于该前沿报告，梳理智能体软件工程范式变革背景、ARC框架技术原理、现存技术痛点、教学实践方案，同时分析产业落地瓶颈与未来研究方向，为Agent软件工程领域提供研究参考。
关键词：智能体软件工程；需求编译；ARC框架；大语言模型；测试驱动开发；DSL领域特定语言
一、引言
传统软件工程流程以人工编码为核心，需求、设计、编码、测试环节由人主导完成。生成式大模型出现后，单轮提示词生成小程序代码已经较为成熟，但面对包含数十至数百业务场景的大规模真实业务需求时，通用大模型普遍存在需求理解不全、逻辑幻觉、边界场景遗漏、架构混乱、需求‑代码不可追溯等问题，很难直接产出完整可维护的软件系统，形成AI编程的“复杂性高墙”。
现有Agent编程大多聚焦于代码补全、小脚本生成，缺少一套完整的、工程化的端到端链路：即从非结构化
一、研究背景
大型语言模型（LLM）的发展一直沿着两条轴线推进：
近年来，OpenAI的o系列、Anthropic的扩展思维模型、DeepSeek-R1和Kimi K1.5等工作，让"测试时扩展"成为前沿研究的核心焦点。然而，开源社区在第二条轴上进展迅速，但在第一条轴上却明显滞后——大多数开源模型仍停留在1T参数规模左右。随着越来越复杂的推理和智能体方法被应用于规模相近的预训练模型上，开源进展面临趋同风险，而与最强大专有系统（Claude、GPT系列）的差距可能持续扩大。
与此同时，真实世界的智能体任务需要处理超长上下文（如软件工程仓库、数万页文档、多天跨度的对话），要求模型同时具备大参数规模、长上下文窗口和原生多模态理解能力。Kimi K3正是在这一背景下诞生的：同时推进两条扩展轴，将预训练基础扩展到前所未有的3T类参数规模，同时在1M上下文长度上扩展强化学习、推理努力和长周期交互。
二、要解决什么问题
Kimi K3要解决的核心问题可以概括为以下
本文档基于Strix 多智能体网络安全渗透测试工具，对开源 Java 漏洞实训平台 JavaSecLab 开展深度白盒代码审计与系统性安全渗透测试。依托 Strix 多智能体协同检测能力，本次测试覆盖项目全部源代码、框架配置、业务逻辑及第三方依赖组件，完整挖掘、归类、验证项目内置的各类安全漏洞。
JavaSecLab 作为面向安全学习、代码审计、安全开发与工具测评的综合型 Java 漏洞靶场，集中复现了 Web 安全、代码缺陷、组件漏洞、业务逻辑风险等大量典型安全问题。本次通过 Strix 深度扫描模式，完成全量代码静态分析、漏洞溯源、数据流审计、风险定级与攻击路径复盘，累计检出严重、高危、中危、低危多维度安全漏洞，覆盖反序列化 RCE、SQL 注入、认证绕过、SSRF、XXE、XSS、模板注入、文件操作漏洞及第三方依赖高危 CVE 等核心风险场景。
Strix 命令行帮助文档
一、项目定位与设计哲学
OpenClaw 不是 AI 模型，而是一个开源（MIT）的 AI Agent 运行时框架（Runtime Framework）——它坐在 AI 模型与外部世界之间，作为一个常驻运行的单体运行时网关（Gateway），负责把自然语言指令转化为真实的系统操作。
定位公式：
OpenClaw = Gateway（网关） + Agent Runtime（运行时） + Skills（技能） + Memory（记忆）
五项核心设计哲学：
| 理念 | 说明 |
|---|---|
| Local-first（本地优先） | 数据不离开用户设备，记忆为本地 Markdown，配置为 JSON；使用 Ollama/vLLM 本地模型时内容永不外传 |
| 网关而非框架 | 不是 SDK/库，而是独立运行的控制平面进程 |
| 模型无关（Model-Agnostic） | 一行配置切换 Claude/GPT/Gemini/DeepSeek 等，按任务路由不同模型 |
| 插件化内核 | Skills、Channels、Providers 均可热插拔（v2026.3.22+ 全面插件化） |
| 工程化 Agent | 从聊天机器人升级为任务调度执行系统，强默认不阉割能力，危险路径暴露为操作者可控开关 |
命名含义： Claw（龙虾钳子）= 抓取/操控/执行能力；Open = 完全开源、社区驱动。
基于 strix 1.3.1 源码（
https://github.com/usestrix/strix）逐行核对 CLI 与运行逻辑编写。所有命令参数对应真实代码位置，可直接复制使用。⚠️ 合规前提：Strix 是自动化渗透测试工具，仅可用于你拥有或已获书面授权的应用/资产。未经授权扫描他人系统属于违法行为。本指南所有示例目标均假设你拥有测试权限。
一、项目定位
Strix 是一个开源 AI 渗透测试工具，部署自主 AI agent 团队对应用进行漏洞发现与验证。核心区别于静态扫描器（SAST）：agent 像真实红队一样动态运行代码、构造 PoC、验证可利用性，产出可复现的漏洞报告而非误报堆积。面向开发与安全团队，支持 CI/CD 集成。
仓库：https://github.com/usestrix/strix ｜ 版本：1.3.1 ｜ License：Apache-2.0
二、技术栈
多智能体深度调研成果
一句话结论：六家科技巨头已全部下场做 AI OS，2025–2026 年集中爆发；学界与产业界对其核心要素（记忆 / 决策 / 行动 / 安全四大系统原语）的定义高度收敛——AI OS 已从营销概念变成架构共识，竞争焦点转向「协议路线 vs GUI 路线」与「重构 vs 叠加」。
Section 01 · 新闻背景
2026-07-13：阶跃星辰「四件套」发布，AI OS 之争进入白热化
上海「阶跃终端品牌暨新一代智能体战略发布会」上，大模型公司阶跃星辰一口气发布四件产品，宣称构建「模、软、硬」三位一体闭环，并提出智能体落地的「三堵墙」理论。[1][2]
对象：
iOfficeAI/OfficeCLI（https://github.com/iOfficeAI/OfficeCLI） 时间线：研究 → 安装到 WorkBuddy → 能力验证 → 三格式展示文档 文档性质：将「深度研究」与「本机实践」合并沉淀，既含结论也含可复现的操作记录
〇、一句话结论
OfficeCLI 是面向 AI Agent 的 Office 自动化套件：一个单文件二进制（内嵌 .NET 运行时，零安装、零外部依赖），提供对 Word / Excel / PowerPoint 的读、改、建能力，并用「高保真渲染 + 确定性 JSON 路径寻址」让 Agent 既能算、也能看见自己生成的排版（render → look → fix 闭环）。经本机实测，README 宣称的核心能力全部成立。它当前仅作为 WorkBuddy 用户级技能 安装在本机（~/.workbuddy/skills/officecli/），可被本 WorkBuddy 实例直接调用。
一、项目研究结论（深度）
1.1 定位与本质 类别：面向 AI Agent 的 Office 文档自动化工具 / AI 中间件（Agent 与 .docx/.xlsx/.pptx 之间的适配层，本身不是聊天机器人）。 技术本质： 单文件二进制：内嵌 .
本文件研究了
/Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked/resources/templates目录下的全部*.tpl模板（12个文件），每个文件作为独立章节，原文（含 Jinja 占位符与 XML 标签）原样保留在代码块中。 基于你提供的 WorkBuddy Prompt 模板文件，以下是其整体架构与各模板关系的思维导图（Mermaid 格式）：
mindmap
root((WorkBuddy Prompt 模板))
分类与概览
共12个模板
分类：模式提醒 / 系统提醒 / 身份上下文 / 主Prompt
主Prompt分4个场景：Ask·编码 / Ask·通用 / Craft·编码 / Craft·设计 / 专家·编码 / 专家·通用 / 通用Craft
模式提醒片段
ask-mode-reminder
Ask模式硬性规则：只读·不编辑·不运行命令
建议切换至Craft
craft-mode-reminder
Craft模式能力激活：可自由编辑与创建文件
直接执行任务
系统提醒片段
system-reminder
占位标签
运行时由系统注入提醒
身份上下文模板
user-context-expert-identity
专家模式身份注入
含BOOTSTRAP.md / USER.md
聚焦产品身份与语气占位
user-context-identity
通用身份注入
含SOUL.md / IDENTITY.md / USER.md
用户自定义指令与语气风格覆盖
主Prompt·Ask模式
workbuddy-ask-prompt
纯对话场景
只读工具·不可编辑
可视化工具（read_me / show_widget）
MCP配置引导
workbuddy-ask-coding-prompt
Ask + 编码场景
与ask-prompt同源
强调代码库上下文与只读分析
主Prompt·Craft模式
workbuddy-prompt
通用Craft默认主提示
能力总览·Agent循环·结果呈现
自动化任务与技能管理
workbuddy-craft-coding-prompt
Craft + 编码场景
Agent循环·任务管理工具
技能积累与反思（SkillManage）
自动化（automation_update）
可视化与多模态生成
workbuddy-craft-design-prompt
Craft + 设计场景
智能设计助手角色
画布三段式回复格式
文生UI·截图验证
目标节点优先原则
主Prompt·专家模式
workbuddy-expert-prompt
专家模式通用（AGENTIC）
角色覆盖·产物概览
松弛自然沟通风格
多模态生成与技能积累
workbuddy-expert-coding-prompt
专家 + 编码场景
与expert-prompt同源
聚焦编码任务与产物交付
该图清晰呈现了：
模板概览
本文记录 AI 生态工作台（open-ai-eco）通过 ACP（Agent Client Protocol） 接入本地 Agent 的完整实践：选型理由、架构设计、关键实现、踩坑经验与验证方法。
1. 背景与目标
工作台是组内的 Astro 站点，用于展示 AI 研究成果。日常工作中沉淀了一批 Agent 技能（Skill）：
这些技能原本只能在终端里通过 Claude Code / Kimi CLI 使用。目标是：在工作台网页里加一个交互入口，直接在页面上对话、调用技能、审批文件操作，把"打开终端敲命令"变成"打开网页点一下"。
约束条件：主要自用、部署在内网 Node 常驻服务上、本地同时装有 Claude Code 与 Kimi CLI 两个 Agent。
2. 为什么选 ACP
数据来源：
codebuddy-plugins-official市场 manifest（共 207 个插件，2026-07-16） 整理口径：从 207 个插件中筛出 软件开发生命周期、安全、办公、设计 四个领域；一个插件只归入一个主领域，跨领域插件在说明中以「兼属 ××」标注；其余 32 个插件列入文末「未归入」。
一、软件开发生命周期（134）
1.1 需求、规划与项目管理（8）
| 插件名 | 来源 | 说明 |
|---|---|---|
| requirements-driven-workflow | 官方 | 需求驱动开发工作流，含 90% 质量门控的功能实现流程 |
| interview | 外部 | 访谈式命令，用于细化大型功能计划与规格 |
| conductor | 外部 | 上下文驱动开发：上下文 → 规格与计划 → 实施的结构化工作流 |
| agent-team-agile-workflow | 官方 | BMAD 敏捷工作流，含 PO、架构师、SM、开发、QA 角色代理与交互式审批 |
| taskmaster | 外部 | 基于 AI 的任务管理系统，提供命令、代理和 MCP 集成 |
| commands-project-setup | 外部 | 项目初始化与搭建命令 |
| commands-project-task-management | 外部 | 任务管理与项目跟踪命令 |
| feature-dev | 官方 | 全面功能开发工作流，含代码库探索、架构设计与质量审查智能体 |
1.2 架构与设计（软件架构）（7）
数据来源：
codebuddy-plugins-official市场 manifest（共 207 个插件）
分类方式：基于插件
name/description关键词的中文功能聚类（官方category字段缺失较多，故采用描述推断）。
分类概览：腾讯安全实验室：7 | 语言服务器 LSP：11 | 文档与办公：11 | 前端与 UI 设计：37 | 游戏开发：5 | 腾讯生态与 MCP 集成：16 | 工作流与生产力：77 | 内容创作与写作：7 | 系统与脚本开发：5 | 外部领域合集：31
腾讯安全实验室（7）
研究对象是 WorkBuddy 桌面客户端的安装包——更准确地说，是它解包后的
resources/与cli/两个目录。我们想知道两件事：（1）对话时「我」到底由什么拼成？ （2）「我」能调用哪些模型、这些模型又从哪来？
答案出人意料地干净：它们分别落在两套声明式配置文件里——提示词模板库与产品配置文件。你此刻正在阅读的「我」，本质上就是这两套文件在运行时的一次实例化。
0. 为什么值得写
平时我们用 AI 助手，关注的是「它能不能帮我干活」。但如果你想知道「它是怎么被造出来的」，安装包本身就是最好的教材：没有编译混淆、没有黑盒，所有「性格」「能力边界」「可用武器」都白纸黑字写在那里。
这次我们顺着两条主线往下挖：
resources/templates/ 下的 19 个文件（约 2400 行），决定了「我是谁、能做什么、如何行动」。cli/product*.json 下的 5 个文件，声明了「我能调用哪些模型、怎么路由、怎么计费」。一、主线 A：提示词模板体系（"我"的大脑）
1.1 三层结构
resources/templates 不是一堆散落的提示词，而是一套以「角色」为主轴、以「模式」为运行时约束的模板工程体系，基于 Jinja2 风格语法（{{ var }} 占位符 + {% if
数据来源：
cli/product.ioa.json（iOA 部署渠道覆盖层）
共 82 个模型条目，按路由代号（vendor）分组。
一、概览
路由代号（vendor）分布
| 路由代号 | 数量 | 说明 |
|---|---|---|
e |
33 | 外部聚合（多为国内厂商模型） |
f |
22 | 首方/海外聚合 |
tencent |
7 | TACO 代码补全/轻量子模型通道（非对话模型，能力字段为 None） |
j |
7 | 特定海外模型 |
i |
2 | iOA 专属条目 |
None |
11 | 未标注（auto/default 等特殊聚合项） |
注意：vendor 是后端路由代号，并非明文厂商名；同一逻辑模型在不同渠道 vendor 可能不同（例如
minimax-m2.5在基座是f、在 cloudhosted 是e）。下表「推测来源」列按模型 id 名称推断，仅供参考，非配置字段。
推理档位（reasoning.effort）分布
| effort 档位 | 数量 |
|---|---|
| medium | 25 |
| (无effort字段) | 17 |
| high | 8 |
计费倍率（credits）分布
空值 = 未显式声明（按渠道默认计费，多为 x1.00）。
研究对象：
/Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked/（WorkBuddy 应用解包目录） 核心结论：可用模型不是硬编码在程序里，而是由cli/目录下一组声明式产品配置文件（product*.json） 定义。机制为「一个基座 + 四个部署覆盖层」，运行时由环境变量选择渠道并合并生成最终模型清单。
一、模型定义的落点
模型定义全部集中在 cli/ 目录下的 5 个产品配置文件里，resources/ 目录中没有模型定义（那里是提示词模板、技能、插件）。
一、目录总览
resources/templates/ 共包含 15 个模板文件，组织为 4 个功能层级 + 1 个风格库：
一套面向 Agent 应用设计者的系统化设计原则、架构模式与实战指南。
基于对 WorkBuddy（CodeBuddy Code）工作空间源码、系统提示词、文档与架构的深度分析提炼而成。
目录
1. 概述：从 Chatbot 到 Agent 的范式跃迁
1.1 Chatbot 和 Agent 的本质区别
| 维度 | Chatbot | Agent |
|---|---|---|
| 核心能力 | 理解并回答 | 理解、计划、执行、验证 |
| 与环境的交互 | 被动接收文本 | 主动感知文件系统、网络、工具 |
| 输出的性质 | 文本回答 | 实际行动（文件变更、API 调用、部署） |
| 正确性保障 | 依赖训练数据 | 通过执行测试、编译、对比等方式自我验证 |
| 会话生命周期 | 一问一答，无持续性 | 跨多轮持久化，可中断恢复 |
| 用户角色 | 提问者 | 协作者/监督者 |
设计 Agent 系统，首先要完成这个认知跃迁：Agent 不是"更强的 Chatbot"，而是一种全新的交互范式。
1.2 Agent 设计的核心张力
在设计 Agent 系统时，始终面临以下四对核心张力：
全场景智能体工作搭子
开启 AI Agent 办公新范式
AI 专家团 全场景办公
WorkBuddy 是全能 AI 工作台，一人指挥，全行业专家执行，从策略到交付一站搞定
免部署·安装即用 ｜ 多专家·多模型协同 ｜ 全平台·桌面 / 主流 IM / 小程序
100+ 领域专家组成你的虚拟团队，运营、设计、数据、开发等全角色场景覆盖
一句话指令自主规划并交付完整结果
多专家并行协作，一个人顶一支团队
MCP 生态 + 自定义 Skills，能力无限扩展
设计系统（Design System）
设计系统Deepseek-V4-Flash输入（宫崎骏的太空之城风格设计系统）
帮我建立一套完整的 Design System，包含颜色体系、字体层级、间距规则和基础组件规范文档，风格为宫崎骏的太空之城
输出