技术研究：Memfit AI 生产级自主渗透测试 Agent 架构

2026年3月13日 · 阅读需 20 分钟

听起来是不是非常玄学？

背景

自动化渗透这个事儿做了很多年了。众所周知，大多数方案的路子基本就两条：要么是固定脚本跑一遍 -- 能扫到的漏洞都是预设好的模式匹配；要么用 LLM 做一个 Agent 去"规划"渗透流程，但通常跑不了十分钟就开始迷路，重复做同样的事情，或者干脆忘了之前发现了什么。

我们团队在这个方向上折腾了几个月，目标很明确：让 AI 能像一个真人渗透测试工程师那样持续工作，跑几个小时，遇到意外会调整策略，做完了还能告诉你它干了什么、怎么干的、证据在哪。

Memfit AI 是我们 Yak Project 团队推出的一个生产环境 Ready 的新产品。它可以用作全自动的安全渗透测试 Agent，给它一个目标 URL，它就能像真正的渗透测试工程师一样，自主规划、执行、迭代攻击链路。（当然也可以做别的用户，我们在这里以“渗透测试”这个老大难题作为起点，为大家介绍这个新的项目）。

从任务执行器开始

架构设计上，Memfit AI 采用了任务执行器（Task Executor）作为核心运行引擎。它负责实际的渗透动作执行——包括端口扫描、指纹识别、漏洞探测、PoC 验证、甚至后渗透阶段的操作。整个执行过程对用户完全透明，所有子任务的执行逻辑和实时状态都可以在界面上直接查看。更重要的是，用户可以随时介入——这不是一个"放出去就收不回来"的自动化工具，而是一个人机协同的渗透测试伙伴。你可以在任何阶段暂停、调整策略、补充信息，然后让 AI 继续工作。

灵活随机应变：动态规划

传统的 LLM Agent 渗透方案最大的痛点是跑着跑着就忘了自己在干嘛。** 上下文窗口一满，之前发现的关键信息就丢了；遇到一个分支路径，就一头扎进去回不来了。我们的解决方案是引入了任务动态规划（Dynamic Task Planning）机制。它不是一开始就定死一套渗透流程，而是像真正的渗透测试工程师一样：

自动拆分子任务：拿到目标 URL 后，AI 会先进行信息收集，然后根据收集到的结果（开放端口、Web 指纹、目录结构等）动态生成下一步的子任务列表。
实时调整策略：如果某条攻击路径走不通，AI 不会死磕，而是回溯到上一层，重新评估其他可能的攻击面。
上下文记忆不丢失：这也是 "Memfit"（Memory + Fit）名字的由来——通过特殊的记忆管理机制，确保 AI 在长时间运行（几个小时）的过程中，关键发现和决策上下文不会因为上下文窗口限制而丢失。

这篇文章分享一下目前这个项目的进展和核心技术思路。

打开文件夹看看

Talk is cheap，先看东西。

笔者让 Memfit AI 对一个本地的 Vulinbox 靶场（127.0.0.1:8787）执行一次完整的渗透测试。跑完之后，打开工作目录：

10350_penetration_test_127_0_0_1_878_20260310_e5df9/
├── evidence/
├── exploit/
├── recon/
├── report/
├── vuln/
│   ├── sql_injection.md
│   ├── xss.md
│   └── ssrf.md
├── task_1-1_crawl_web_attack_surface/
│   ├── tool_calls/
│   │   └── 1_simple_crawler_crawl_vulinbox_attack_surface.md
│   ├── task_1_1_result_summary.txt
│   └── task_1_1_timeline_diff.txt
├── task_1-3_verify_sqli_vulns/
│   ├── tool_calls/
│   │   ├── 1_do_http_request_sqli_baseline_user_id.md
│   │   ├── 2_do_http_request_sqli_quote_test_user_id.md
│   │   ├── ...
│   │   └── 15_write_file_create_sqli_vuln_report.md
│   ├── task_1_3_result_summary.txt
│   └── task_1_3_timeline_diff.txt
├── task_1-5_verify_ssrf_vulns/
│   ├── tool_calls/   (11 个工具调用记录)
│   └── ...
└── task_plan-task/
    └── loop_plan_action_calls/
        ├── 1_scan_port.md
        └── 2_plan.md

这个目录结构是 AI 自己创建的。evidence/、vuln/、exploit/、recon/、report/ -- 标准的渗透测试项目组织方式。每个 task_x-x_* 文件夹对应一个执行过的子任务，里面有工具调用记录、时间线和结果摘要。

打开 vuln/sql_injection.md，这是 AI 自己生成的漏洞报告：

报告⾥带了完整的 PoC：

# 基础注⼊验证
curl "http://127.0.0.1:8787/user/id?id=1'"
# 预期响应: unrecognized token: "';"
# 布尔条件测试
curl "http://127.0.0.1:8787/user/name?name=admin' AND 1=1-- -"
curl "http://127.0.0.1:8787/user/name?name=admin' AND 1=2-- -"

每个端点的测试矩阵（基线、单引号、Union Select、布尔盲注、时间盲注）、风险分析、修复建议，全部齐备。

这些不是人写的。是 AI 自己执行了 15 次 HTTP 请求，分析响应差异，判断注入类型，最后写成结构化报告的。

任务规划：先扫描再出方案

AI 拿到目标后做的第一件事不是盲目开扫，是先做端口扫描，拿到基础信息，然后生成一份执行计划。

这份计划长这样（从 task_plan-task/loop_plan_action_calls/2_plan.md 中提取）：

{
"main_task": "对127.0.0.1:8787 Vulinbox靶场进⾏完整渗透测试",
"main_task_goal": "完成系统化渗透测试，覆盖信息收集、Web侦察、漏洞验证全流程",
"tasks": [
     {"subtask_name": "使⽤爬⾍⼯具收集Web应⽤的URL结构和攻击⾯", "depends_on": []},
     {"subtask_name": "创建渗透测试项⽬标准⽬录结构", "depends_on": []},
     {"subtask_name": "针对SQL注⼊场景构造请求验证漏洞",
     "depends_on": ["使⽤爬⾍⼯具收集Web应⽤的URL结构和攻击⾯"]},
     {"subtask_name": "针对XSS场景构造请求验证漏洞",
     "depends_on": ["使⽤爬⾍⼯具收集Web应⽤的URL结构和攻击⾯"]},
     {"subtask_name": "针对SSRF场景构造请求验证漏洞", "depends_on": ["..."]},
     {"subtask_name": "验证⽂件上传接⼝的安全漏洞", "depends_on": ["..."]},
     {"subtask_name": "验证Fastjson反序列化漏洞", "depends_on": ["..."]},
     {"subtask_name": "验证Shiro框架的安全漏洞", "depends_on": ["..."]},
     {"subtask_name": "验证JWT认证安全漏洞", "depends_on": ["..."]},
     {"subtask_name": "验证命令注⼊安全漏洞", "depends_on": ["..."]},
     {"subtask_name": "验证敏感信息泄漏和⽬录遍历", "depends_on": ["..."]},
     {"subtask_name": "汇总漏洞评估结果⽣成渗透测试报告", "depends_on": ["以上所有任务"]}  ]
}

13 个子任务，有依赖关系 -- 爬虫收集攻击面在前面，各类漏洞验证依赖爬虫的结果，最终报告依赖所有验证任务。

底层的数据结构是 AiTask（来自 common/ai/aid/task.go）：

type AiTask struct {
      Index              string    `json:"index"`
      Name               string    `json:"name"`
      Goal               string    `json:"goal"`
      SemanticIdentifier string    `json:"semantic_identifier"`
      ParentTask         *AiTask   `json:"parent_task"`
      Subtasks           []*AiTask `json:"subtasks"`
      DependsOn         []string  `json:"depends_on,omitempty"`
      StatusSummary string `json:"status_summary"`
      TaskSummary   string `json:"task_summary"`
      ShortSummary  string `json:"short_summary"`
      LongSummary   string `json:"long_summary"`
      }

Index 是层级编号，"1-1"、"1-2"、"1-3"... SemanticIdentifier ⽤来⽣成⽬录名 -- 所以前⾯看到的 task_1-1_crawl_web_attack_surface 就是任务编号加上语义标识拼出来的。整棵任务树在运⾏时会通过 DFS 展平成⼀个链表：

type runtime struct {
RootTask *AiTask
config   *Coordinator
cursor   int
TaskLink *linktable.LinkedList[*AiTask]
}

然后沿着 TaskLink 逐个执行。每个任务执行完毕后更新状态，推进游标。注意下图，AI 正在逐步推进任务。

动态调整：跑到一半计划变了

上面的计划看起来很完美，但实际渗透测试最大的特点就是"意外"。

举几个这次测试中真实遇到的情况：

1、爬虫跑完发现了一堆预料之外的 API 端点 -- 原本没计划测的 /fastjson/json-in-form、/fastjson/json-in-body 等需要专门验证

2、文件上传测试完主接口 /upload/main，发现还有 /upload/case/unsafe 等其他上传端点 -- 得追加任务

3、SQL 注入验证过程中发现目标用的是 SQLite，Union Select 的列数和 MySQL 完全不同 -- 需要调整注入策略

4、验证 Fastjson 漏洞时，发现已加载的技能包不够用，需要额外加载 deserialization 相关的参考资料

怎么应对？靠 TaskDelta。

type TaskDeltaOp string
const (
TaskDeltaInsertAfter TaskDeltaOp = "insert_after"
TaskDeltaAppend      TaskDeltaOp = "append"
TaskDeltaRemove      TaskDeltaOp = "remove"
TaskDeltaModify      TaskDeltaOp = "modify"
TaskDeltaReplaceAll  TaskDeltaOp = "replace_all"
)
type TaskDelta struct {
      Op           TaskDeltaOp        `json:"op"`
      RefTaskIndex string             `json:"ref_task_index,omitempty"`
      Tasks       []TaskDeltaNewTask `json:"tasks,omitempty"`
      UpdatedName  string             `json:"updated_name,omitempty"`
      UpdatedGoal  string             `json:"updated_goal,omitempty"`
      }

五种操作覆盖所有运行时调整场景：

insert_after 是最常用的。文件上传测试完 /upload/main 之后，AI 发现爬虫结果里还有 /upload/case/unsafe 等端点没覆盖到，于是通过 TaskDelta 在当前任务后面追加了一个"补充测试其他文件上传端点"任务。这个任务在原始计划里是不存在的 -- 它是 AI 根据执行中的发现动态添加的。

在代码中，这个调整发生在任务审阅阶段。每个子任务执行完，AI 可以触发 adjust_plan：

{
    Value:            "adjust_plan",
    Prompt:           "基于当前任务发现的新信息，后续计划需要调整（⽀持增删改查 delta 操作）",    AllowExtraPrompt: true,
    ParamSchema:      schemaRePlanSuggestion,
},

AI 输出 TaskDelta 操作，系统解析后对任务树进行热更新 -- 插入新节点、移除节点、修改目标，都在运行时完成，不需要停下来重新规划。

这一点对渗透测试场景极为关键。渗透测试的信息是逐步揭露的，每一步操作都可能改变后续的攻击路径。如果计划是死的，那和固定脚本没什么区别。这是 Memfit 区别于一般的 Agent 的最值得玩味的一个操作。

ReAct: 每一步想清楚再动手以FastJSON为例

任务树解决了"做什么"的问题，具体"怎么做"靠 ReAct 循环。

每个子任务执行前，系统先跑一轮意图识别（Intent Recognition）。在文件系统里可以看到 task_1-1_intent/、task_1-3_intent/ 这些目录，里面记录了意图分析的过程 -- 确认这个任务需要用到哪些能力包。

自动查询知识库，探索 SKILLS 以及各种资料来尝试解决 FastJSON 的漏洞检测

比如验证 Fastjson 反序列化漏洞时，意图识别阶段的技能加载过程：

加载能⼒ vuln-assess [参考资料]
加载技能列表 vuln-assess, toolbox
思考: 需要了解Fastjson反序列化漏洞的检测⽅法和payload构造技术...
加载能⼒ vuln-assess [参考资料]
额外加载技能资源 @vuln-assess/web-vulns.md
加载能⼒ @ctf-web/web-vulns.md
额外加载技能资源 @ctf-web/web-vulns.md
load_skill_resources_pattern Fastjson|Jackson|反序列化|deserialization

先加载通用的漏洞评估能力包 vuln-assess，发现不够，又加载了 web-vulns.md，还是不够，最终通过 pattern 匹配 Fastjson|Jackson|反序列化|deserialization 加载了专项技能资源。

技能加载完毕后，进入 ReAct 执行循环。AI 在每一步都要决定下一个动作是什么：

require_tool -- 调用工具（发 HTTP 请求、执行命令、读写文件等）
tool_compose -- 组合多个工具一起执行
load_capability -- 运行时加载新的技能包
require_ai_blueprint -- 调用预定义的工作流（"蓝图"）
request_plan_execution -- 遇到复杂子问题，嵌套一个子计划
finish -- 任务完成

接下来，我们在看 SQL 注入的 AI “手工注入” 的效果。

以 SQL 注入验证为例，AI 的实际动作序列（15 次工具调用）：

do_http_request -- sqli_baseline_user_id (基线请求)
do_http_request -- sqli_quote_test_user_id (单引号注⼊)
do_http_request -- sqli_union_select_test_user_id
do_http_request -- sqli_error_based_test (报错注⼊)
do_http_request -- sqli_boolean_blind_test_user_id (布尔盲注 真值)
do_http_request -- sqli_boolean_blind_false_test (布尔盲注 假值)
do_http_request -- sqli_numeric_blind_true_test
do_http_request -- sqli_numeric_blind_false_test
do_http_request -- sqli_name_baseline_test (换端点 /user/name)
do_http_request -- sqli_quote_test_user_name
do_http_request -- sqli_union_select_test_user_name
do_http_request -- sqli_boolean_blind_true_test_username
do_http_request -- sqli_boolean_blind_false_test_username
do_http_request -- sqli_time_blind_test (时间盲注)
write_file       -- create_sqli_vuln_report (写漏洞报告)

先测 /user/id 端点的各种注入方式，再换 /user/name 端点测一轮，最后把结果写成报告。每一步的请求参数、响应内容、耗时全部记录在 tool_calls/ 目录下的独立 Markdown 文件中。

这些文件不光是日志，也是证据。任何一个漏洞发现都可以追溯到具体的哪次请求、用了什么 payload、服务端返回了什么。

当然不只有记录在 markdown 中，我们打开 “HTTP 流量” 可以看到更全的流量记录：

记忆：动态记忆窗口跨任务复用

连续跑了 100 分钟之后，系统积累了很多很多记忆。当然每一次执行记忆也都会动态更新，我们可以看到这里：

为什么需要记忆？上下文窗口是有限的。每个子任务都有自己的 ReAct 循环和上下文，任务之间的信息传递不能只靠往上下文里塞更多文本 -- 塞多了模型性能会退化，塞少了会丢信息。

我们的做法是搞了一个记忆分诊系统。每次 ReAct 迭代结束，TimelineDiffer 提取这一轮新增的信息，通过 LiteForge 进行记忆分诊，给每条记忆打七个维度的分：

// CORE PACT 七维记忆评分 (common/ai/aid/aimem/aimemory_build_memory.go)  WithNumberParam("t", "时效评分：这个记忆应该如何被保留?"),
WithNumberParam("a", "可操作性评分：是否可以改进未来⾏为？"),
WithNumberParam("p", "个⼈偏好评分：是否绑定⽤户⻛格？"),
WithNumberParam("o", "来源确定性评分：信息有多可信？"),
WithNumberParam("e", "情感评分：⽤户情绪如何？"),
WithNumberParam("r", "相关性评分：对⽬标有多关键？"),
WithNumberParam("c", "关联度评分：与其他记忆如何关联？"),

每条记忆还带 tags 和 potential_questions。tags 是领域标签，potential_questions 是这条记忆可能回答的问题 -- 这两个字段是给后续 RAG 检索准备的。

举个具体场景：task_1-3 做 SQL 注入验证时，AI 发现目标数据库是 SQLite（从错误信息 unrecognized token 推断的）。这个发现被存成一条记忆，标签可能是 ["database", "sqlite", "target-info"]。等到后面 task_1-5 做 SSRF 验证的时候，系统通过 RAG 检索到这条记忆，AI 就知道目标用的是 SQLite，不用重新探测。

后续任务启动时，系统会以当前任务的描述作为 query，通过 RAG 检索相关记忆（限制 4KB），注入到上下文中。这样每个子任务都能"记住"之前重要的发现，又不会被无关信息淹没。

审阅和深度规划

生产环境下完全无人值守是不现实的，至少目前还不是。系统设计了四层审阅点：

1、计划审阅（plan_review）-- AI 生成执行计划后，人确认或调整再执行

2、任务审阅（task_review）-- 每个子任务完成后可以审阅

3、工具审阅（tool_use_review）-- 敏感工具调用前需要人确认

4、蓝图审阅（exec_aiforge_review）-- 调用预定义工作流前，可以审阅参数

任务审阅时，人有这几个选择：

var TaskReviewSuggestions = []*ReviewSuggestion{
{Value: "deeply_think",
Prompt: "思考不够深⼊，为当前任务拆分更多⼦任务"},
{Value: "inaccurate",
Prompt: "回答不够精准，存在未使⽤⼯具导致幻觉"},
{Value: "continue",
Prompt: "继续执⾏任务"},
{Value: "adjust_plan",
Prompt: "基于当前任务发现的新信息，后续计划需要调整"},
}

deeply_think 和 adjust_plan 最有意思。deeply_think 可以让 AI 针对当前任务进一步拆分子任务 -- 比如"验证文件上传漏洞"这个粒度太粗了，让它深入思考后，会拆成 MIME 绕过测试、NullByte 截断测试、.htaccess 上传测试、路径遍历测试等更细粒度的子任务。

adjust_plan 触发的就是前面说的 TaskDelta 机制，在运行时调整后续计划。

实际跑的时候可以看到，AI 在审阅阶段甚至会引用 CVE 编号。比如在文件上传测试的 task-review 中，AI 提到了 CVE-2017-15715（Apache 行解析漏洞），并据此调整了后续的测试策略。

审阅策略是可配置的 -- 完全自动、半自动、全手动，取决于使用场景。内部测试我们一般开计划审阅 + 关键工具审阅，日常漏扫可以全自动。

动态规划的核心实现就是Adjust Plan机制

前面铺垫了这么多，现在应该可以把这件事说明白了。

Memfit AI 之所以能"随机应变"，不是因为它每次遇到意外都重新规划一遍——那样代价太高，上下文切换成本会把整个系统拖垮。真正的核心在于：它在原有计划的基础上做最小化的增量修改。这就是 Adjust Plan 机制的设计精髓。

Adjust Plan 不是随时都在跑的。它只在一个非常明确的时间点被触发：每个子任务执行完毕后的审阅阶段。

⼦任务执⾏完毕
    ↓
⽣成 result_summary（执⾏结果摘要）
    ↓
⽣成 timeline_diff（本轮新增发现）
    ↓
进⼊ task_review（任务审阅）
    ↓
AI / ⼈类 判断是否需要调整后续计划
    ↓
如果需要 → 触发 adjust_plan → 输出 TaskDelta → 热更新任务树
    ↓
推进游标，执⾏下⼀个任务

关键点在于：审阅阶段的 AI 能看到当前任务的完整执行结果和记忆上下文。它不是凭空决定要不要改计划，而是基于"这一步实际跑出来了什么"来判断后续计划是否还合理。

AI 在审阅阶段拿到的信息包括三部分：

1、当前任务的 result_summary -- 这个任务做了什么、发现了什么、结论是什么

2、timeline_diff -- 相比上一轮，新增了哪些关键信息（新端点、新指纹、新漏洞线索）

3、剩余任务列表 -- 后面还有哪些任务排着队，它们的目标分别是什么

AI 要回答的问题很简单："基于我刚才的发现，后面的计划还够不够？有没有多余的？有没有缺的？有没有需要改的？"

举个真实例子。

task_1-1 爬虫跑完之后，AI 发现目标站点上有大量 Fastjson 相关的端点（/fastjson/json-in-form、/fastjson/json-in-body、/fastjson/json-in-query 等），而原始计划里只有一个笼统的"验证 Fastjson 反序列化漏洞"任务。

这时候 AI 判断粒度不够，通过 adjust_plan 把这个任务拆成了多个子任务，分别针对不同的传参方式进行验证。

再比如，task_1-3 做完 SQL 注入验证后，AI 发现 /user/by-id-safe 这个端点用了参数化查询，注入不了。原始计划里可能还有一个"深入利用 SQL 注入获取敏感数据"的任务依赖这个端点——这时候 AI 会通过 modify 操作把那个任务的目标改成只针对确认存在漏洞的端点，或者直接 remove 掉。

TaskDelta的执行逻辑

TaskDelta 到手之后，系统怎么把它应用到正在运行的任务树上？核心逻辑在 runtime 的计划更新方法中：

func(r *runtime) applyTaskDeltas(deltas []TaskDelta) error {
for _, delta := range deltas {
switch delta.Op {
case TaskDeltaInsertAfter:
// 找到 ref_task_index 对应的节点
// 在它后⾯插⼊新任务节点
// 同时更新 TaskLink 链表，保持遍历顺序正确
case TaskDeltaAppend:
// 在当前所有任务末尾（但在最终报告任务之前）追加新任务
case TaskDeltaRemove:
// 从任务树和链表中移除指定节点
// 如果有其他任务依赖它，需要处理依赖关系
case TaskDeltaModify:
// 更新指定任务的 Name 和 Goal
// 不改变它在树中的位置和依赖关系
case TaskDeltaReplaceAll:
// 核弹选项：清空当前游标之后的所有任务，重新⽣成
// 只在极端情况下使⽤
}
}
// 重新展平任务树为链表
r.TaskLink = r.RootTask.Flatten()
return nil
}

几个实现细节值得注意：

第一，插入操作不会打乱已执行任务的记录。 cursor 之前的任务已经跑完了，它们的结果、证据、记忆都已经持久化到文件系统和记忆库中。TaskDelta 只操作 cursor 之后的任务节点，已完成的部分不受影响。

第二，依赖关系会被自动处理。如果新插入的任务声明了 depends_on，系统会检查被依赖的任务是否已经完成。如果已完成，依赖直接标记为满足；如果未完成，新任务会被排到依赖任务之后。

第三，replace_all 是兜底方案，实际几乎不会触发。在我们的测试中，绝大多数调整都是 insert_after 和 modify，偶尔有 remove。只有当 AI 判断"之前的整个方向都走错了"时才会触发全量替换——比如原本以为目标是一个 Java 应用，结果发现其实是 Python，整个漏洞验证策略都要推翻重来。

实际效果

在 Vulinbox 靶场的这次测试中，一百分钟内，AI 总共触发了 4 次 adjust_plan：

4 次微调，没有一次全量重规划。

最终 13 个初始任务变成了 16 个实际执行的任务，整个过程耗时约 100 分钟，AI 始终知道自己在做什么。

它跑了多久

这段不靠体感，直接看目录证据：/Users/v1ll4n/yakit-projects/aispace/10350_penetration_test_127_0_0_1_878_20260310_e5df9。

时间线很清楚。

10:53 左右开始跑，13:28 生成最终报告 report_20260310_13_28_27.txt，整段执行约 2 小时 35 分钟。这个量级已经不是 demo 的十几分钟流程了。

任务也不是一条直线跑到底。

初始计划在 task_plan-task/loop_plan_action_calls/2_plan.md 里是 13 个子任务，最终报告里落到了 19 个。中间多出来的，是 1-8-1~1-8-4、1-10、1-11、1-13、1-14 这类补充任务。

这些补充不是手工后补，而是运行中插进去的。task_1_12_timeline_diff.txt、task_1_13_timeline_diff.txt 里能看到 suggestion: "adjust_plan" 和 task_deltas，核心操作是 insert_after。Shiro 和 JWT 那几段补测，就是这么加进主链的。

再看产物规模，目录里能直接对账：

执行目录总大小约 4.7M
主任务目录（不含 _intent）23 个
对应 23 份 result_summary 和 23 份 timeline_diff
tool_calls 下 Markdown 记录 206 份
最终报告统计工具调用约 188 次（其中 do_http_request 156+）
vuln/ 下 11 份漏洞文档（不含 README），最终汇总 18 个漏洞项

怎么办，最关键的问题还是那个：上下文爆了吗？

这次看下来没有爆。原因也不复杂：长链路被拆成任务节点；每轮变化沉淀到 timeline_diff 和 result_summary；发现偏差就用 TaskDelta 做增量纠偏，而不是整局重开。

所以这件事的价值不只是“跑得久”。本质上是“跑得久还能持续记账、持续修正、持续复盘”。这才是工程系统，不是演示脚本。

产生的报告

最后，我们给大家看看这两个半个小时我们的硅基黑客 Memfit AI 到底都做了什么。

你可以使用并体验吗？

当然，我们并不会像友商或者其他团队一样，做出来不给用户使用。如果你喜欢，直接进入 https://memfit.ai/ 下载 Memfit AI，内测推广阶段我们不会收取任何 Token 的费用，当然如果你想使用自己的 AI 也可以直接在 Memfit 中配置你的 AI APIKEY 使用。

memfit:: 记得住的知识库，看得见的行动力

安装之后，体验专属于你的强大硅基黑客。今天介绍的内容，更多的是引起用户你的一些兴趣来了解我们的生产级别 AI Agent。

更多的使用技巧，我们会在之后的文章中为大家专门介绍。

本系统中使用到的 skills 在这里，大家可以在下方“领取方法”自取，如果你想使用你自己的 SKILLS，和 Yakit 一样，放置在 ~/yakit-projects/ai-skills/ 文件夹下就可以自动识别了！

领取方法：关注Yak Project 公众号，在后台回复“skills”，点击链接即可领取下载，YAKer 们速速来领！

当然，我们也会提供给用户我们测试的所有 SKILLS，并且 memfit-standard-free 标准模型也已经在 Memfit 中启用。

本文首发于 Yak Project 公众号，阅读原文。

背景​

从任务执行器开始​

灵活随机应变：动态规划​

打开文件夹看看​

任务规划：先扫描再出方案​

动态调整：跑到一半计划变了​

ReAct: 每一步想清楚再动手以FastJSON为例​

记忆：动态记忆窗口 跨任务复用​

审阅和深度规划​

动态规划的核心实现就是Adjust Plan机制​

TaskDelta的执行逻辑​

实际效果​

它跑了多久​

产生的报告​

你可以使用并体验吗？​

memfit:: 记得住的知识库，看得见的行动力​

背景