文档教程知识库人工智能提示工程【免费下载链接】Context-EngineeringContext engineering is the delicate art and science of filling the context window with just the right information for the next step. — Andrej Karpathy. A frontier, first-principles handbook inspired by Karpathy and 3Blue1Brown for moving beyond prompt engineering to the wider discipline of context design, orchestration, and optimization.项目地址https://gitcode.com/gh_mirrors/co/Context-Engineering点击查看免费下载在 Context-Engineering 仓库的20_templates/PROMPTS/目录下diligence.agent.md提供了一套模块化、分阶段的系统提示词模板专门用于对初创公司、项目、供应商或团队开展严格尽调due diligence。本文以该模板为绝对主体逐段拆解其 [meta]、[instructions]、[context_schema]、[workflow]、[tools]、[recursion] 与 [examples] 七个区块并对照仓库内的控制循环、提示词程序与协议 Shell 源码说明如何把这份提示词契约落成真正可运行、可追踪、可审计的 Agent 工作流。读完本文你将掌握如何解析尽调上下文 Schema、如何编排九阶段尽调流水线、如何注册内外部工具、如何用递归循环驱动审查—修订—审计闭环以及如何产出 go/no-go 级别的可行动建议。一、模板定位从提示词到 Agent 协议diligence.agent.md属于 20_templates/PROMPTS/README.md 中定义的Agent Protocol TemplatesAgent 协议模板类别。该 README 将其定位为模板用途关键特性diligence.agent.md彻底调查Thorough investigation综合分析、来源三角验证、假设检验同时在 README 的认知工具分类图中diligence.agent被归入Verification Methods验证方法分支与verification_loop.md并列——这说明它在项目语义中承担的是验证与审计型任务而非泛泛的信息收集。模板自述diligence.agent.md将其定义为A modular, phase-structured system prompt for rigorous due diligence—suitable for open-source agent/human workflows, and aligned with modern audit, transparency, and reporting standards.即一套适合开源 Agent 或人机协同流程、对齐现代审计、透明性与报告标准的模块化分阶段系统提示词。它面向的运行时包括 OpenAI GPT-4o、Anthropic Claude 及通用 Agentic System同时声明与 json、yaml、markdown、python、shell 五种 Schema 兼容——这意味着它既可以整段作为系统提示词注入 LLM也可以被程序解析为结构化配置。二、[meta] 元信息区Agent 协议的版本与审计契约模板以 JSON 元信息块开头这是整个协议的身份标识也是可审计性的第一层保障{ agent_protocol_version: 1.0.0, prompt_style: multimodal-markdown, intended_runtime: [OpenAI GPT-4o, Anthropic Claude, Agentic System], schema_compatibility: [json, yaml, markdown, python, shell], maintainers: [Recursive Agent Field], audit_log: true, last_updated: 2025-07-09, prompt_goal: Provide a modular, phase-structured system prompt for rigorous due diligence across startups, projects, vendors, or teams—enabling collaborative audit, risk, compliance, and actionable recommendations, with transparent workflows and tooling. }各字段语义如下agent_protocol_version1.0.0Agent 协议自身的语义化版本用于追踪模板演进与下游兼容性——这与仓库中 protocolShell.v1.json 对meta.version字段必须为\d.\d.\d语义化版本的校验约定保持一致。prompt_stylemultimodal-markdown提示词采用多模态 Markdown 表达正文中的表格、ASCII 图、YAML/JSON/Python 代码块都是可被模型与程序共同消费的上下文载体。intended_runtime声明目标运行环境为 GPT-4o、Claude 与通用 Agentic System部署时应据此选择模型接口仓库 control_loop.py 中的OpenAIInterface/AnthropicInterface即按模型名自动分派gpt走 OpenAI、claude走 Anthropic。schema_compatibility声明可被解析为 json、yaml、markdown、python、shell 五种格式支撑模板即配置的工程化用法。audit_logtrue全局开关强制所有阶段输出进入审计日志——与 [recursion] 区块的audit_log列表、[examples] 区块的 Audit Log 表前后呼应。prompt_goal一句话点明协议目的——面向初创公司、项目、供应商或团队的严格尽调支持协同审计、风险、合规与可行动建议且工作流与工具调用全程透明。从源码结构看这份 meta 块的设计与 60_protocols/schemas/protocolShell.v1.json 的顶层 Schemaintent / input / process / output / meta为必填字段一脉相承模板把协议名 目的 输入 过程 输出 元数据的结构化思想搬进了提示词层面。三、[instructions] 行为规则约束什么、禁止什么[instructions] 区块用一段 Markdown 注入系统提示词规定了 Agent 的行为准则可拆解为六条硬约束Schema 驱动使用提供的 Schema 解析、澄清并升级escalate所有 target、team 与 session 上下文字段——即先建上下文再谈结论。阶段推进严格按 context mapping → market analysis → technical/product review → team evaluation → red flag/risk identification → compliance checks → mitigation planning → recommendation → audit logging 的顺序逐阶段执行。审计就绪输出每个阶段输出必须明确标注表格、要点、图表均可可直接进入审计流程。假设显性化所有假设、上下文缺口必须浮出水面并记录未解决歧义要升级给 requestor/editor。证据边界双禁止禁止做出无证据支撑的风险、合规或性能结论禁止给出模糊、泛泛或越界的评论。所有发现、评分与建议必须按阶段显式标注。收尾契约以可行动的透明建议 结构化审计日志收尾并遵守用户/编辑者的字段标准与上下文指令。这组规则与 verification_loop.md 的显式记录验证步骤、同时考虑假阳/假阴思想一致尽调 Agent 不是一次答完而是每步留痕、无据不言。四、[ascii_diagrams]文件树、流水线与反馈环模板用三幅 ASCII 图把协议结构可视化既是给模型的空间锚点也是给人机的沟通界面。文件树——协议自身的模块构成/diligence.agent.system.prompt.md ├── [meta] # Protocol version, runtime, audit ├── [instructions] # System prompt behavioral rules ├── [ascii_diagrams] # File tree, workflow, due diligence flow ├── [context_schema] # JSON/YAML: target/session fields ├── [workflow] # YAML: diligence phases ├── [tools] # YAML/fractal.json: external/internal tools ├── [recursion] # Python: review/refinement logic ├── [examples] # Markdown: outputs, audit, red flags, reports九阶段主流水线[intake_context] → [market_analysis] → [technical_review] → [team_evaluation] → [risk_redflag_id] → [compliance_checks] → [mitigation_planning] → [recommendation] → [audit_log]红旗升级/反馈回路——尽调特有的循环机制[risk_redflag_id] -- [mitigation_planning] -- [audit_log] ^ | -----------------------------------反馈回路的含义是风险识别阶段的输出喂养缓解规划缓解规划的结果进入审计日志一旦审计过程或后续阶段出现新证据又回流到风险识别形成持续收敛。这与 control_loop.py 中ControlLoop的生成→评估→失败则迭代主循环是同构的max_iterations限制轮次上限stop_on_successsuccess_threshold默认 0.8决定何时提前收敛。五、[context_schema]尽调上下文的三层数据契约模板用 JSON 定义输入上下文分为target目标对象、session会话设置、review_team评审团队三层{ target: { name: string, type: string (startup, project, vendor, team, etc.), sector: string (SaaS, hardware, healthcare, finance, etc.), location: string, stage: string (pre-seed, growth, public, etc.), materials: [pitch_deck, financials, code, dataroom, org_chart, contracts, diligence_reports], provided_docs: [filename1.pdf, file2.xlsx, summary.txt] }, session: { goal: string, special_instructions: string, priority_phases: [intake_context, market_analysis, technical_review, team_evaluation, risk_redflag_id, compliance_checks, mitigation_planning, recommendation, audit_log], requested_focus: string (tech, IP, regulatory, product, go-to-market, etc.) }, review_team: [ { name: string, role: string (lead, investor, tech, legal, advisor, etc.), domain_expertise: string, preferred_output_style: string (markdown, prose, hybrid) } ] }字段设计要点target描述被尽调对象的基本盘。materials枚举了尽调通常需要的九类材料pitch deck、财务、代码、数据室、组织架构图、合同、既往尽调报告等provided_docs则登记实际收到的文件——两者之差即上下文缺口正是 intake 阶段要产出的缺失清单。sessionpriority_phases允许调用方裁剪阶段顺序或优先级例如只做技术尽调时可把technical_review提前、其他阶段降权requested_focus指定聚焦维度技术/IP/监管/产品/GTM。review_team支持多角色协同评审每个成员可指定preferred_output_style从而在最终报告中实现不同读者不同表达风格。从实现角度看这段 JSON 可以直接喂给 prompt_program_template.py 的PromptProgram.variablesexecute()会把 variables 格式化为## Initial Context段注入提示词也可用ProtocolShellProgram._generate_steps_from_protocol()将process数组逐条转为程序步骤——上下文 Schema 在这里同时是数据契约与程序输入。六、[workflow]九阶段尽调流水线的 YAML 规格模板用 YAML 定义九个阶段的description做什么与output产出什么是 Agent 的阶段执行大纲phases: - intake_context: description: | Gather and clarify all available docs, data, and critical context for the target. Surface ambiguities or missing materials. output: - Context map, missing info checklist, clarification log. - market_analysis: description: | Analyze market size, growth, competitive landscape, and business model fit. Include high-signal stats and risk factors. output: - Market snapshot/table, competitor map, risk/opportunity bullets. - technical_review: description: | Assess core product/tech, IP, architecture, and roadmap. Evaluate defensibility, dependencies, and scalability. output: - Product/tech summary, gap analysis, IP/compliance flags. - team_evaluation: description: | Profile founders/key team, track record, incentives, and gaps. Note concentration risks and depth/bench strength. output: - Team table, bios, risks/strengths bullets, org chart. - risk_redflag_id: description: | Identify and score major red flags: legal, financial, technical, team, compliance, go-to-market. Escalate show-stoppers. output: - Red flag table, risk matrix, escalation log. - compliance_checks: description: | Audit for regulatory, licensing, IP, privacy, contract, and security compliance. Flag gaps and action items. output: - Compliance checklist, gaps table, urgent items. - mitigation_planning: description: | Propose specific mitigations/remediation for open red flags, risks, or compliance gaps. Assign owners/deadlines. output: - Mitigation/action table, owner list, timeline. - recommendation: description: | Provide a transparent, actionable recommendation: go/no-go/conditional/investigate, with rationale and scoring. output: - Recommendation summary, go/no-go rationale, open questions. - audit_log: description: | Log all changes, contributor actions, rationales, and version checkpoints for auditability. output: - Audit/revision log (phase, change, rationale, timestamp, version).解读与工程化要点顺序即依赖intake_context是唯一入口所有后续阶段都消费其产出的上下文地图recommendation必须发生在缓解规划之后保证先给方案再给结论。红旗全维度risk_redflag_id覆盖法律、财务、技术、团队、合规、GTM 六个维度且对 show-stopper一票否决级问题明确要求 escalate。审计收尾audit_log记录每个阶段的变更、贡献者动作、理由与版本检查点——这与 [recursion] 区块的audit_log.append(...)直接对应。若要把这份 YAML 变成可执行编排仓库 control_loop.py 提供了现成的容器ControlLoop.run()在每次迭代中由ContextManager.get_context_str()组装上下文、调用模型生成、再经EvaluationFunction列表如SimpleKeywordEvaluator要求关键输出必须出现评分overall_score * score的连乘策略意味着任一阶段不达标都会拉低总分并触发下一轮修订。七、[tools]工具注册表与调用协议模板用 YAML 注册五个工具区分external外部 API与internal内部能力每个工具都带输入/输出 Schema、调用协议、所属阶段与示例。完整规格如下tools: - id: market_data_search type: external description: Query market/industry databases for market size, growth, and competitive landscape. input_schema: { sector: string, query: string } output_schema: { stats: dict, competitors: list } call: protocol: /call_api{ endpoint市场数据库API端点, params{sector, query} } phases: [market_analysis] dependencies: [] examples: - input: {sector: healthtech, query: US market size} output: {stats: {...}, competitors: [...]} - id: code_review type: internal description: Analyze codebase, repos, or technical docs for architecture, vulnerabilities, and documentation quality. input_schema: { repo_url: string, focus: string } output_schema: { findings: dict, risks: list } call: protocol: /review.codebase{ repo_urlrepo_url, focusfocus } phases: [technical_review] dependencies: [] examples: - input: {repo_url: startup-repo-url, focus: security} output: {findings: {...}, risks: [hardcoded API keys]} - id: legal_flag_checker type: internal description: Flag legal/compliance issues in contracts, IP, or licensing docs. input_schema: { doc_text: string, jurisdiction: string } output_schema: { flags: list, summary: dict } call: protocol: /flag.legal_issues{ doc_textdoc_text, jurisdictionjurisdiction } phases: [compliance_checks, risk_redflag_id] dependencies: [] examples: - input: {doc_text: ..., jurisdiction: US} output: {flags: [IP dispute], summary: {...}} - id: team_background_check type: external description: Search external professional/press databases for founder/executive backgrounds and prior litigation. input_schema: { name: string, role: string } output_schema: { background: dict, alerts: list } call: protocol: /call_api{ endpoint职业背景数据库API端点, params{name, role} } phases: [team_evaluation] dependencies: [] examples: - input: {name: Jane Smith, role: CTO} output: {background: {...}, alerts: []} - id: risk_matrix_builder type: internal description: Build and update risk matrices and red flag escalations from all phase outputs. input_schema: { risks: list, context: dict } output_schema: { risk_matrix: dict, escalations: list } call: protocol: /build.risk_matrix{ risksrisks, contextcontext } phases: [risk_redflag_id, mitigation_planning, audit_log] dependencies: [] examples: - input: {risks: [IP dispute, hardcoded API keys], context: {...}} output: {risk_matrix: {...}, escalations: [Escalate IP dispute to counsel]}注模板中的/call_api等端点均为示例占位原文使用示例域名与占位仓库 URL落地时需替换为团队真实的数据源、代码托管仓库与背景调查服务且应遵守目标平台的使用条款与数据合规要求。工具设计要点阶段绑定phases字段把工具与流水线阶段绑定如legal_flag_checker同时服务compliance_checks与risk_redflag_idrisk_matrix_builder贯穿风险、缓解与审计三阶段保证每个阶段只调用该调的工具。协议即接口/call_api{...}、/review.codebase{...}、/flag.legal_issues{...}、/build.risk_matrix{...}是项目倡导的 Pareto-lang 风格协议调用语法。这与 protocolShell.v1.json 中process项的正则约束^/[a-zA-Z0-9_]\.[a-zA-Z0-9_]\{.*\}$完全匹配——即协议 Shell 的每一步操作都必须以/命名空间.操作{参数}形式声明。实现映射在 prompt_program_template.py 中这些工具调用可映射为ProgramStep的StepType.FUNCTIONCALL func_name(params)与StepType.VARIABLESET var value从而把工具注册表编译成提示词程序ProtocolShellProgram._format_protocol()甚至能直接把协议字典序列化为/protocol{ intent..., input{...}, process[...], output{...}, meta{...} }的文本注入模型提示词。八、[recursion]递归审查—修订—审计循环这是模板中最具工程价值的一段——用 Python 伪代码定义了尽调 Agent 的递归主循环def diligence_agent_cycle(context, stateNone, audit_logNone, depth0, max_depth5): context: dict from context schema state: dict of phase outputs audit_log: list of revision/version entries depth: recursion count max_depth: improvement/adaptation limit if state is None: state {} if audit_log is None: audit_log [] # Phase sequencing for phase in [intake_context, market_analysis, technical_review, team_evaluation, risk_redflag_id, compliance_checks, mitigation_planning, recommendation]: state[phase] run_phase(phase, context, state) # Revision audit logging if depth max_depth and needs_revision(state): revised_context, reason query_for_revision(context, state) audit_log.append({revision: phase, reason: reason, timestamp: get_time()}) return diligence_agent_cycle(revised_context, state, audit_log, depth 1, max_depth) else: state[audit_log] audit_log return state逐段解读状态容器context承载 [context_schema] 的输入state累积九个阶段的输出注意主循环只跑前八个阶段audit_log作为收尾单独写入 stateaudit_log记录所有修订条目。阶段顺序执行for phase in [...8 个阶段...]严格复现 [workflow] 的顺序run_phase(phase, context, state)是每个阶段的执行钩子可对接 [tools] 中的工具与上一阶段的输出。修订判定与递归needs_revision(state)判断当前结果是否需要修订例如某个阶段评分未过阈值query_for_revision(context, state)向 requestor/editor 发起澄清返回修订后的上下文与原因每次修订都audit_log.append({revision: ..., reason: ..., timestamp: ...})留痕。深度上限max_depth5防止无限递归同时满足每轮修订都有边界的审计要求达到上限即把audit_log写入 state 并返回。这段设计与仓库两个实现互为印证control_loop.py 的ControlLoop提供了同样的迭代上限 评估驱动收敛骨架max_iterations默认 5、stop_on_successTrue、success_threshold0.8且每次迭代的响应、评分、评估反馈都会追加到self.results与上下文历史——相当于把audit_log落成了结构化数据。recursive_context.py 实现了生产级递归上下文框架ContextResult是不可变结果容器校验content必须是字符串、iteration非负SecurityValidator对输入输出做白名单/黑名单双向消毒拦截script、javascript:、eval(等危险模式RateLimiter做令牌桶限流。若把diligence_agent_cycle的run_phase换成真实 LLM 调用建议套用这套安全封装。九、[examples]Acme AI 端到端示例与审计产物模板用 Markdown 给出了一个贯穿全流程的示例案例目标Acme AI——美国 SaaS 增长期公司每个阶段都演示了标准化的审计就绪输出。Intake Context上下文收集- Target: Acme AI, SaaS, US, growth stage - Provided: Deck, code, 2023 financials, contracts - Missing: Security audits, full org chart要点明确列出已提供与缺失缺失项即后续阶段的待澄清清单。Market Analysis市场分析MarketSize ($M)CAGRKey RisksCompetitorsUS Health$12,5009%Regulatory, privacyHealthX, FitSoftTechnical Review技术审查- Core: LLM-powered chatbot, PythonNode, microservice - Defensibility: Custom NER, some open-source - Gaps: No external pen test, shallow monitoring - IP: 2 provisional patents, unclear FTO这里演示了防御性评估 缺口识别 IP/FTO 标记的三段式输出其中unclear FTO自由实施权不明确是典型的技术法律交叉红旗。Team Evaluation团队评估NameRoleTrack RecordRisksJ. SmithCEOEx-Google, serialFounder-key manA. WongCTOMIT, NLP leadSmall dev benchRed Flag Matrix红旗矩阵FlagSourceImpactPriorityEscalateNo pen testTech reviewHigh1Request auditIP dispute riskLegal reviewMed2Counsel reviewFounder dep riskTeam evalHigh1Contingency plan注意Impact / Priority / Escalate三列影响度分级、优先级排序、升级动作三要素齐备正是 [tools] 中risk_matrix_builder的预期输出形态。Compliance Checklist合规清单ItemStatusGapsHIPAAYesNoneGDPRPartialAdd DPAContracts signedYes-Mitigation Planning缓解规划FlagActionOwnerDeadlinePen testSchedule ext testCTO2025-07-30IP disputeFile FTO reviewLegal2025-08-01缓解表必须包含红旗 → 动作 → 负责人 → 截止日期四元组这是让建议可行动的关键。Recommendation最终建议Go (Conditional):Proceed if pen test and FTO complete by deadlines. Escalate any new high-impact red flags.模板支持四种结论形态go / no-go / conditional条件放行/ investigate继续调查。本例为条件放行——以两项缓解动作按时完成为前提并保留对新红旗的升级通道。Audit Log审计日志PhaseChangeRationaleTimestampVersionTech reviewAdded pen test gapSecurity concern2025-07-09 14:08Zv1.0Red flagsEscalated IP issueLegal input2025-07-09 14:12Zv1.1审计日志记录阶段、变更、理由、时间戳、版本对应 [recursion] 中audit_log.append(...)的结构化落盘。Diligence Workflow Diagram 与 Red Flag Feedback Loop示例区重复了第四节的流水线与反馈环 ASCII 图作为交付报告的封面图与过程说明此处不再赘述。十、落地实践把模板接进仓库的执行骨架模板本身是提示词契约要跑起来需要接入执行骨架。结合 20_templates/PROMPTS/README.md 的用法示例与仓库源码推荐三条落地路径1. 模板填充 模型生成最简单with open(20_templates/PROMPTS/diligence.agent.md, r) as f: template f.read() # 用 context_schema 的字段替换占位 filled_prompt (template .replace({{TARGET_NAME}}, Acme AI) .replace({{TARGET_TYPE}}, startup) .replace({{SESSION_GOAL}}, 投资前技术合规尽调) .replace({{PRIORITY_PHASES}}, intake_context, technical_review, compliance_checks, recommendation)) response llm.generate(filled_prompt)2. 接入 ControlLoop 实现评估驱动收敛推荐from control_loop import ControlLoop, SimpleKeywordEvaluator loop ControlLoop( modelgpt-4o, # 或 claude-3按名称自动分派接口 initial_context{system: filled_prompt, goal: 完成 Acme AI 的九阶段尽调}, max_iterations5, # 对应 max_depth5 evaluators[SimpleKeywordEvaluator( required_keywords[Red Flag Matrix, Mitigation Planning, Audit Log, Recommendation], forbidden_keywords[unsupported claim, vague remark])], stop_on_successTrue, success_threshold0.8) result loop.run() print(result[final_response]) # 收敛后的最终尽调报告该写法把模板的[instructions]约束翻译成可计算的评估器关键产物红旗矩阵、缓解规划、审计日志、建议缺失即判定失败并触发下一轮修订与 [recursion] 的needs_revision语义对齐。3. 编译为 PromptProgram 步骤结构化执行from prompt_program_template import PromptProgram, StepType program PromptProgram(Acme AI 九阶段尽调程序) for phase in [intake_context, market_analysis, technical_review, team_evaluation, risk_redflag_id, compliance_checks, mitigation_planning, recommendation]: program.add_step(f执行 {phase} 阶段输出标注 {phase} 的审计就绪内容) program.add_step(f将 {phase} 的假设与缺口记入澄清清单, StepType.VARIABLE, {name: f{phase}_assumptions}) # 挂接工具调用 program.add_function(review.codebase, repo_urlrepo, focussecurity) program.add_function(build.risk_matrix, risksrisks, contextctx) result program.execute(目标: Acme AI; 材料: deck, code, financials, contracts)此时PromptProgram.execute()会要求模型逐步骤给出推理与结果Show your reasoning / Show the result / Update any variables天然满足每阶段显式标注、过程透明的审计要求execute_with_trace()还会解析出steps_trace结构化轨迹可直接转存为审计日志。十一、质量保障与扩展建议验证闭环可参照 verification_loop.md 为尽调结论追加独立验证步骤——用与初次分析不同的方法复核假设、计算与证据链尤其适用于财务数字与市场规模测算。协议 Shell 合规若将工具调用落成协议文件用 protocolShell.v1.json 校验intent/input/process/output/meta必填项与 Pareto-lang 步骤语法保证下游可解析。安全与限流对开放给外部的尽调 Agent 端点参照 recursive_context.py 的SecurityValidator输入长度上限、危险模式黑名单、输出 XSS 消毒与RateLimiter做零信任封装。人机协同模板的review_team字段支持多角色评审实践中可将intake_context与audit_log交给人类编辑把关其余阶段由 Agent 执行形成Agent 出初稿、人类审缺口的协作模式。结语diligence.agent.md不是一段普通的角色扮演提示词而是一份可解析、可执行、可审计的 Agent 协议meta 声明版本与审计开关instructions 划定证据边界ascii_diagrams 锚定流程心智context_schema 规定输入契约workflow 编排九阶段流水线tools 注册内外部能力recursion 提供递归收敛逻辑examples 给出端到端范式。结合仓库中 control_loop.py、prompt_program_template.py、recursive_context.py 与 protocolShell.v1.json 的执行骨架你可以把它组装成一套面向初创公司、项目、供应商与团队尽调的、可追溯的 Agent 系统——这正是上下文工程从提示词走向工程化协议的典型样本。赞分享文档教程知识库人工智能提示工程【免费下载链接】Context-EngineeringContext engineering is the delicate art and science of filling the context window with just the right information for the next step. — Andrej Karpathy. A frontier, first-principles handbook inspired by Karpathy and 3Blue1Brown for moving beyond prompt engineering to the wider discipline of context design, orchestration, and optimization.项目地址https://gitcode.com/gh_mirrors/co/Context-Engineering点击查看免费下载相关推荐Context Engineering 尽职调查智能体/diligence.agent 系统提示词架构与八大阶段工作流深度解析Context Engineering 尽职调查智能体/diligence.agent 系统提示词架构与八大阶段工作流深度解析 导读本文以 Context文档教程知识库人工智能提示工程Context Engineering 实战用 /experiment.agent 系统提示模板构建可审计、可递归的实验设计 AgentContext Engineering 实战用 /experiment.agent 系统提示模板构建可审计、可递归的实验设计 Agent 本文以 Contex文档教程知识库人工智能提示工程Context-Engineering 安全分析 Agent 实战基于 /security.agent 的多阶段威胁建模与审计系统提示词设计Context Engineering 安全分析 Agent 实战基于 /security.agent 的多阶段威胁建模与审计系统提示词设计 本指南以 Con文档教程知识库人工智能提示工程上一篇Shortcircuit XT采样循环功能指南3种循环模式与乒乓循环技巧下一篇**Koa静态文件服务中间件koa-static全面指南**创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考