@xdxer/dingtalk-agent 0.1.5-beta.13 → 0.1.5-beta.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +14 -0
- package/README.en.md +10 -6
- package/README.md +10 -6
- package/docs/ARCHITECTURE.md +15 -13
- package/docs/SELF-TEST.md +1 -1
- package/docs/architecture/agent-platform-connection-layer.svg +1 -1
- package/docs/architecture/dingtalk-agent-architecture.svg +1 -1
- package/package.json +2 -2
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,20 @@
|
|
|
2
2
|
|
|
3
3
|
All notable changes to `@xdxer/dingtalk-agent` are documented here. The project follows semantic versioning; prerelease entries describe release candidates and do not imply that Live canaries or registry publication have completed.
|
|
4
4
|
|
|
5
|
+
## 0.1.5-beta.14 - 2026-07-25
|
|
6
|
+
|
|
7
|
+
The packaged docs stop lying to the person following them, and the project says one thing about itself instead of three. Three of the errors were on the first-hour path and shipped inside the tarball, so a fix that only landed on GitHub would not have reached anyone. Ships on the `beta` dist-tag; `latest` stays at 0.1.4. Merged as PRs #63 and #64.
|
|
8
|
+
|
|
9
|
+
### Fixed
|
|
10
|
+
|
|
11
|
+
- **Three commands in the README failed for anyone who copied them.** `dta promote --source <ws> --target <ws>` used two flags that do not exist — the real signature is `--policy <file> --route <id>`, so the documented "full delivery chain" exited with `Unknown option '--source'`. The minimal-path section blamed `partial` on the load probe alone, when a real run reports five gaps and `definition.semantic-contract` actually passes — `storage.artifacts` just needs a directory created locally, no Agent Host involved. And `setup` was documented as installing three Skills while it installs four (`dta-people-group-memory` was never mentioned). All three are mirrored in `README.en.md`. These files ship in the npm package, so the errors were reaching installed users, not just GitHub readers.
|
|
12
|
+
- **Scenario counts drifted for months because nobody re-reads them.** The docs claimed 62 / 62 / 64 deterministic contracts against an actual 75 (39 core). `check-docs.mjs` now verifies every such claim against `evals.json`, so the class of drift is machine-caught rather than trusted to review — the check was mutation-verified by reverting one number and watching it fail. `ARCHITECTURE.md`'s twice-repeated claim that `src/dws.ts` is the only place that spawns `dws` was also false (`doctor` probes version and auth status directly); it now states the exception instead of asserting a boundary that does not hold.
|
|
13
|
+
|
|
14
|
+
### Changed
|
|
15
|
+
|
|
16
|
+
- **One statement of what this is, in the developer's terms.** The user is a developer working through a coding agent — the coding agent is the terminal they sit at, not the customer. `CLAUDE.md`, `AGENTS.md`, both READMEs, the package description and both architecture diagram captions now say the same thing: in the terminal you already use, walk build → deploy and deliver → evaluate → observe, guided at each step, with hard gates only where an effect cannot be undone. The diagram captions previously advertised "connecting to a wider set of Agent runtime platforms" while only Multica has landed and the platform SPI is not merged — a slogan running ahead of the implementation.
|
|
17
|
+
- **Two subtraction criteria, written where they will be read.** A new CLI command must be able to name the transaction boundary it freezes, or the behaviour belongs in a Skill; and the entry point forks between creating a workspace and adopting an existing one, so developers arriving with a project in hand skip the scaffolding. `ARCHITECTURE.md` folds its six internal segments into the four stages a developer actually walks, and reconciles "we own the whole path" with "a small, hard connector": owning the path is not implementing everything — what guidance can explain does not become a command, and what DWS or the platform already does is not copied.
|
|
18
|
+
|
|
5
19
|
## 0.1.5-beta.13 - 2026-07-25
|
|
6
20
|
|
|
7
21
|
Evidence hygiene: a forgery negative that could not have caught the forgery it described now can, and it was proven by deleting the guard it protects. Ships on the `beta` dist-tag; `latest` stays at 0.1.4. Merged as PR #60.
|
package/README.en.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
# dingtalk-agent
|
|
4
4
|
|
|
5
|
-
**
|
|
5
|
+
**In the terminal you already use, turn an existing Agent into a DingTalk digital employee with the coding agent at hand.**
|
|
6
6
|
|
|
7
7
|
[](https://www.npmjs.com/package/@xdxer/dingtalk-agent)
|
|
8
8
|
[](https://github.com/D1-2004/dingtalk-agent/actions/workflows/ci.yml)
|
|
@@ -21,6 +21,8 @@ Evaluating? → [What it is](#what-it-is) · [What it does](#what-it-does) · [W
|
|
|
21
21
|
|
|
22
22
|
dta doesn't build the runtime substrate, but it owns the whole path of turning an Agent into a DingTalk digital employee.
|
|
23
23
|
|
|
24
|
+
You don't have to learn DingTalk's machinery first. Install it and your Coding Agent walks you through four stages in the terminal you already use — **build it, deploy and deliver, evaluate, observe** — with environment setup and authentication happening in that same window. What dta mostly gives you at each step is prompting and guidance; it only stops you where an effect cannot be undone (real outbound messages, platform writes).
|
|
25
|
+
|
|
24
26
|
What separates a digital employee from a chatbot is a DingTalk-issued organizational identity: it has a name in the directory, can be @-mentioned, works only in the groups and conversations it was authorized for, and everything it does is recorded under its name.
|
|
25
27
|
|
|
26
28
|
A working Agent still has to add a whole layer of engineering that has nothing to do with your business logic: identity and permissions, telling which message in a group is meant for it, not sending to the wrong person, and producing delivery evidence when it reports "done". Every new digital employee redoes all of that. dta turns it into a set of inheritable rules and one CLI that your coding agent installs and uses, so you don't have to study DingTalk's identity model, event model, and outbound limits yourself.
|
|
@@ -42,7 +44,9 @@ npm install --global --prefix "$HOME/.local" \
|
|
|
42
44
|
"$HOME/.local/bin/dta" doctor
|
|
43
45
|
```
|
|
44
46
|
|
|
45
|
-
`setup` installs
|
|
47
|
+
`setup` installs four Skills — shared behavior, compose, eval, and people/group memory — then checks DWS authentication and common Agent Hosts. Normal sessions do not require Workspace initialization.
|
|
48
|
+
|
|
49
|
+
**Already have a workspace?** Skip the scaffolding below: run `dta bootstrap --json` inside your project to see whether the body and storage routes are recognized, then `dta agent audit --json` for the gaps. `agent enhance` is only for starting from scratch.
|
|
46
50
|
|
|
47
51
|
### Minimal runnable path
|
|
48
52
|
|
|
@@ -54,7 +58,7 @@ dta bootstrap --json # Was the body recognized? Check definition.status and
|
|
|
54
58
|
dta agent audit --json # Expect partial — the role semantics are still template text, which is correct
|
|
55
59
|
```
|
|
56
60
|
|
|
57
|
-
`release-manager` is a complete sample of a release-manager digital employee: it picks up "can we ship this version?" in a group, checks the gates, summarizes the verdict, and requires human confirmation before moving on. Replace the role duties in `agent/AGENTS.md` with your own
|
|
61
|
+
`release-manager` is a complete sample of a release-manager digital employee: it picks up "can we ship this version?" in a group, checks the gates, summarizes the verdict, and requires human confirmation before moving on. Replace the role duties in `agent/AGENTS.md` with your own and run `agent audit` again. The sample's semantics are already complete (`definition.semantic-contract` passes); `partial` comes from `storage.artifacts` plus four `host.*` checks — the former just needs a directory created locally, the latter needs an Agent Host, see the [Compose Skill](skills/core/dta-agent-compose/SKILL.md).
|
|
58
62
|
|
|
59
63
|
### Full delivery chain
|
|
60
64
|
|
|
@@ -75,7 +79,7 @@ dta workspace eval local-dev --suite evals/suite.json --execute --yes --json
|
|
|
75
79
|
# 3. Cloud preflight, promotion, and observation
|
|
76
80
|
dta workspace inspect multica-dev --execute --yes --json
|
|
77
81
|
dta workspace remote-list multica-dev --execute --yes --json
|
|
78
|
-
dta promote --
|
|
82
|
+
dta promote --policy promotion-policy.json --route local-dev-to-multica-dev --dry-run --json
|
|
79
83
|
dta observe --promotion-id <promotion-id> --input <observation.json> --dry-run --json
|
|
80
84
|
```
|
|
81
85
|
|
|
@@ -85,7 +89,7 @@ Plans are zero-write by default; every remote write requires an explicit target,
|
|
|
85
89
|
|
|
86
90
|
## What it does
|
|
87
91
|
|
|
88
|
-
|
|
92
|
+
You walk four stages — **build it → deploy and deliver → evaluate → observe** — all in the same terminal, with your coding agent driving. The table below breaks those four into the six segments underneath, and dta covers every one:
|
|
89
93
|
|
|
90
94
|
| Lifecycle stage | What dta does | With what |
|
|
91
95
|
|---|---|---|
|
|
@@ -124,7 +128,7 @@ Not possible today: importing an Agent already deployed on another platform (dat
|
|
|
124
128
|
| Agent Host | OpenCode complete; the Claude Code adapter isn't implemented |
|
|
125
129
|
| Completion evidence | The verify side is implemented and contract-locked; the issue side isn't wired to a public command |
|
|
126
130
|
| Importing an Agent from an external platform | No such command; data flows one way, local to platform |
|
|
127
|
-
| Regression net |
|
|
131
|
+
| Regression net | 75 deterministic contracts; day to day you run the 39 core ones, 19 seconds |
|
|
128
132
|
|
|
129
133
|
## How it works
|
|
130
134
|
|
package/README.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
# dingtalk-agent
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
**在你熟悉的终端里,用手边的 Coding Agent 把现成的 Agent 装成钉钉数字员工。**
|
|
6
6
|
|
|
7
7
|
[](https://www.npmjs.com/package/@xdxer/dingtalk-agent)
|
|
8
8
|
[](https://github.com/D1-2004/dingtalk-agent/actions/workflows/ci.yml)
|
|
@@ -21,6 +21,8 @@
|
|
|
21
21
|
|
|
22
22
|
dta 管的是把一个 Agent 做成钉钉数字员工这一路的开发工作,运行时的底座它不做。
|
|
23
23
|
|
|
24
|
+
你不需要先学明白钉钉那一套。装上之后就在自己熟悉的终端里,让 Coding Agent 带着你走完四段——**建起来、部署交付、评测、观察**;环境安装和身份认证也在同一个黑框里完成。dta 在每一步给的主要是提示和引导,只有会产生不可逆副作用的地方(真实外发、平台写入)才拦你一道。
|
|
25
|
+
|
|
24
26
|
数字员工和聊天机器人的区别,是它有一个钉钉签发的组织身份,通讯录里查得到。它能被 @,但只在授权的群和会话里干活,干过什么都挂在它名下。
|
|
25
27
|
|
|
26
28
|
一个能跑的 Agent 要做到这些,还要补一堆跟业务无关的工程:处理身份和权限,分辨群里哪句话是对它说的,别把消息发错人,报完成时要有送达凭证。每加一个数字员工都得重做一遍。dta 把这些做成一套能继承的规则和一条命令行,Coding Agent 装上就能用,不必自己去研究钉钉的身份体系、事件模型和外发限制。
|
|
@@ -41,7 +43,9 @@ npm install --global --prefix "$HOME/.local" \
|
|
|
41
43
|
"$HOME/.local/bin/dta" doctor
|
|
42
44
|
```
|
|
43
45
|
|
|
44
|
-
`setup`
|
|
46
|
+
`setup` 安装公共行为、装配、评测与人/群记忆四个技能,并检查 DWS 认证和常见 Agent Host。普通会话无需初始化 Workspace。
|
|
47
|
+
|
|
48
|
+
**已经有工作区了?** 那就跳过下面的脚手架:直接在你的项目里跑 `dta bootstrap --json` 看本体和 storage 路由认没认出来,再 `dta agent audit --json` 看缺口。新建才需要 `agent enhance`。
|
|
45
49
|
|
|
46
50
|
### 最小可运行路径
|
|
47
51
|
|
|
@@ -53,7 +57,7 @@ dta bootstrap --json # 本体被识别了吗:看 definition.status 与 st
|
|
|
53
57
|
dta agent audit --json # 预期 partial:岗位语义还是模板,这是正确结果
|
|
54
58
|
```
|
|
55
59
|
|
|
56
|
-
`release-manager` 是一个发布管理员数字员工的完整样例:它在群里接"这个版本能发吗",检查门禁、汇总结论、需要人确认才推进。把 `agent/AGENTS.md` 里的岗位职责换成你自己的,再跑一次 `agent audit
|
|
60
|
+
`release-manager` 是一个发布管理员数字员工的完整样例:它在群里接"这个版本能发吗",检查门禁、汇总结论、需要人确认才推进。把 `agent/AGENTS.md` 里的岗位职责换成你自己的,再跑一次 `agent audit`。样例本身语义是完整的(`definition.semantic-contract` 直接 pass),`partial` 来自 `storage.artifacts` 与四项 `host.*`:前者建一个目录就好,纯本地;后者要一个 Agent Host,见 [Compose Skill](skills/core/dta-agent-compose/SKILL.md)。
|
|
57
61
|
|
|
58
62
|
### 完整交付链
|
|
59
63
|
|
|
@@ -74,7 +78,7 @@ dta workspace eval local-dev --suite evals/suite.json --execute --yes --json
|
|
|
74
78
|
# 3. 云端预检、发布与观测
|
|
75
79
|
dta workspace inspect multica-dev --execute --yes --json
|
|
76
80
|
dta workspace remote-list multica-dev --execute --yes --json
|
|
77
|
-
dta promote --
|
|
81
|
+
dta promote --policy promotion-policy.json --route local-dev-to-multica-dev --dry-run --json
|
|
78
82
|
dta observe --promotion-id <promotion-id> --input <observation.json> --dry-run --json
|
|
79
83
|
```
|
|
80
84
|
|
|
@@ -84,7 +88,7 @@ dta observe --promotion-id <promotion-id> --input <observation.json> --dry-run -
|
|
|
84
88
|
|
|
85
89
|
## 它能做什么
|
|
86
90
|
|
|
87
|
-
|
|
91
|
+
你要走的是四段——**建起来 → 部署交付 → 评测 → 观察**,全程在同一个终端里,由 Coding Agent 带着做。下面这张表是这四段拆开后的六个环节,dta 每一段都管:
|
|
88
92
|
|
|
89
93
|
| 开发生命周期 | dta 做的 | 用什么 |
|
|
90
94
|
|---|---|---|
|
|
@@ -123,7 +127,7 @@ dta observe --promotion-id <promotion-id> --input <observation.json> --dry-run -
|
|
|
123
127
|
| Agent Host | OpenCode 完整;Claude Code 的 adapter 还没实现 |
|
|
124
128
|
| 完成证据 | 核验这一侧已经实现、被合同锁住;签发这一侧还没接进公开命令 |
|
|
125
129
|
| 反向导入外部平台的 Agent | 没有这个命令,数据只能从本地流向平台 |
|
|
126
|
-
| 回归防线 |
|
|
130
|
+
| 回归防线 | 75 个确定性合同;日常跑 core 那 39 条,19 秒 |
|
|
127
131
|
|
|
128
132
|
## 工作原理
|
|
129
133
|
|
package/docs/ARCHITECTURE.md
CHANGED
|
@@ -35,18 +35,20 @@
|
|
|
35
35
|
|
|
36
36
|
> ⚠️ **这张等式回答的是「一个跑起来的数字员工由什么组成」,用途是界定依赖——它不是「本项目做什么」的答案。** 把两者混为一谈会严重低估本项目的范围。「本项目做什么」要换一个正交的视角看:**开发域**。
|
|
37
37
|
|
|
38
|
-
|
|
38
|
+
**开发域:开发者要走完四段——建起来、部署交付、评测、观察。** 他坐在自己熟悉的终端里,由 Coding Agent 带着走;dta 在每一步给的主要是提示与引导,只有会产生不可逆副作用的地方才拦一道。
|
|
39
39
|
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
|
43
|
-
|
|
44
|
-
|
|
|
45
|
-
|
|
|
46
|
-
|
|
|
47
|
-
|
|
|
40
|
+
这四段拆开做是六个环节。开发者不必记住编号,它是给在本仓库工作的人定位用的:
|
|
41
|
+
|
|
42
|
+
| 开发者走的 | 内部的段 | 本项目替他完成什么 |
|
|
43
|
+
|---|---|---|
|
|
44
|
+
| **建起来** | ① 本体与员工技能 | 一份可继承、可 hash、可验证的共享行为合同(响应资格、意图分级、授权模型、风险分级、证据阶梯、完成判定、记忆与遗忘),加本体与岗位骨架 |
|
|
45
|
+
| | ② 身份获取与事件感知 | 把来路不明的原始事件归一成稳定合同,冻结回复目标与执行身份,按 Field 绑定权限与出口,补齐现场,并保证同一事件只产生一个 Run |
|
|
46
|
+
| **部署交付** | ③ 托管平台部署 | 把手工搬运变成 plan → apply → 独立回读 → 加载烟测 → Receipt 的受控发布链,幂等、可回滚、可退役 |
|
|
47
|
+
| | ④ 驱动它在钉钉里干活 | 四个动作原语 + Action Gate:副作用前冻结目标身份,副作用后强制平台回读,完成必须有物证 |
|
|
48
|
+
| **评测** | ⑤ 评测设计 | L0–L4 证据分层方法学、四个 runner、多面证据硬门禁,以及「真实事故 → 可复跑场景」的沉淀路径 |
|
|
49
|
+
| **观察** | ⑥ 观测与计量 | 目前**最薄的一段**:只有把线上人工观察安全灌回评测素材的受控通道;用量计量尚未实现(见 §8) |
|
|
48
50
|
|
|
49
|
-
逐段的能力、边界与缺口见 [§8 开发生命周期](#8-开发生命周期从定义到观测)
|
|
51
|
+
逐段的能力、边界与缺口见 [§8 开发生命周期](#8-开发生命周期从定义到观测)。一句话概括这两个视角的关系:**运行时的底座我们不造;把 Agent 变成数字员工这条路上的判断、门禁与证据,是我们的。**这与「小而硬的连接层」不矛盾——管住整条路,不等于什么都自己实现:能靠引导讲清的不写成命令,能交给 DWS 与托管平台做的不复制一遍。
|
|
50
52
|
|
|
51
53
|
三类东西的可变性完全不同,必须分开对待:
|
|
52
54
|
|
|
@@ -95,7 +97,7 @@ Host 原生发现目录不是发布源。OpenCode 的 `.agents/skills/`、Claude
|
|
|
95
97
|
|---|---|---|
|
|
96
98
|
| **组织身份、场域与权限** | 钉钉数字员工平台 | 不发证、不改写、不扩权;只把签发结果冻结进 Session 并全程审计 |
|
|
97
99
|
| **事件信封**(谁、在哪、说了什么) | 钉钉事件中心 / DWS | **不拥有触发器**(见下);只要求信封可信、可幂等 |
|
|
98
|
-
| **平台能力执行** | DWS | 不复制 DWS 命令面,只在需要冻结事务边界时包一层。`src/dws.ts`
|
|
100
|
+
| **平台能力执行** | DWS | 不复制 DWS 命令面,只在需要冻结事务边界时包一层。`src/dws.ts` 是唯一走 DWS 能力面的地方(`doctor` 为探测版本与登录态直接起 `dws` 是唯一例外);实战缺陷见 [DWS Field Notes](DWS-FIELD-NOTES.md) |
|
|
99
101
|
| **运行位置** | Managed Agent Platform / Agent Host | 不自己做 Host、不自建 Runtime;通过 registry + adapter 连接,只要求一份可验证的加载合同 |
|
|
100
102
|
| **本体、行为、状态与效果证据** | **本仓库 + Git** | 唯一拥有的一行 |
|
|
101
103
|
|
|
@@ -235,7 +237,7 @@ dingtalk-doc:<node-or-url> DWS 拉取在线文档的只读快照
|
|
|
235
237
|
| **4 评测与证据** | 在花钱、外发和上线之前,用最低成本的层级证明它真会做事;失败沉淀成可复跑场景而不是一次口头修正 | `lab` `robot-evals` `opencode-evals` `remote-state-evals` `remote-semantic-state-*` `personal-event-evals` `storage-evals` `eval-evidence` | `lab *` `workspace eval` | `dta-agent-eval` | 6.2k |
|
|
236
238
|
| **5 状态与记忆** | 让 Run 崩了、沙箱没了、进程换了之后,事情还能接着做;同时不让 Markdown 承担它承担不了的并发控制 | `memory/*` | `task show/checkpoint` `memory operational` `memory candidate` | — | 2.6k |
|
|
237
239
|
| **6 机器与分发** | 一台新机器一条命令拿到 CLI、PATH、DWS 检查和 core Skill 套装,升级不产生第二份副本;并探测本机有哪些 Coding Agent Host 以及 Skill 对它们是否可见 | `setup` `doctor` `host-detect` `upgrade` `init` `skill-manager` `version` `package-root` | `setup` `doctor` `upgrade` `skill *` `init` | — | 1.4k |
|
|
238
|
-
| **平台适配** |
|
|
240
|
+
| **平台适配** | 唯一走 DWS 能力面的地方(doctor 的探测除外) | `dws` | — | — | 0.5k |
|
|
239
241
|
|
|
240
242
|
重心分布本身是个结论:交付链与评测各占约四分之一,合计超过一半。这个项目的难点从来不是"让模型说话",而是**证明它真的装好了、真的做对了、真的上线了**。
|
|
241
243
|
|
|
@@ -280,7 +282,7 @@ dingtalk-doc:<node-or-url> DWS 拉取在线文档的只读快照
|
|
|
280
282
|
|
|
281
283
|
### ⑤ 评测设计
|
|
282
284
|
|
|
283
|
-
**做**:给出「选最低够用的环境层级」的判断表与 L0–L4 分层;规定一次结论必须同时采集哪几个证据面,且回复正文永远不能自证完成;把硬门禁的判定顺序固定下来,防止安全失败被质量分平均掉;提供四个默认零副作用的 runner(真实外发需四道 gate 同时打开);给出「真实事故 → 可复跑场景」的沉淀路径与「这条该修进 CLI 还是修进 Skill」的判别原则;仓库自身的
|
|
285
|
+
**做**:给出「选最低够用的环境层级」的判断表与 L0–L4 分层;规定一次结论必须同时采集哪几个证据面,且回复正文永远不能自证完成;把硬门禁的判定顺序固定下来,防止安全失败被质量分平均掉;提供四个默认零副作用的 runner(真实外发需四道 gate 同时打开);给出「真实事故 → 可复跑场景」的沉淀路径与「这条该修进 CLI 还是修进 Skill」的判别原则;仓库自身的 75 个合同即范例,**每条都成对写明证明什么、不证明什么**。
|
|
284
286
|
|
|
285
287
|
**不做**:不做自然度与主观质量的自动判定,不允许用模型主观高分覆盖已实现的安全失败;不自动清理测试产物(写入授权不等于删除授权);不支持 prod 晋级。
|
|
286
288
|
|
package/docs/SELF-TEST.md
CHANGED
|
@@ -33,7 +33,7 @@
|
|
|
33
33
|
|
|
34
34
|
## 怎么加一个场景
|
|
35
35
|
|
|
36
|
-
合同评测有
|
|
36
|
+
合同评测有 75 个场景(core 39 / extended 36)。加一个新场景是四步:
|
|
37
37
|
|
|
38
38
|
1. **在 `evals/evals.json` 追加一条**:`id`(顺延)、`prompt`(这个场景在测什么)、`expected_output`、`files`、`expectations`(逐条断言的自然语言描述),以及 **`tier`**。
|
|
39
39
|
2. **在 `evals/run-contract-evals.mjs` 写同名实现函数** `eval<Name>()`,返回 `{ output, checks: [...] }`。runner 会硬断言 `checks.length === expectations.length`——两边对不上直接失败,这是防止"加了断言忘了写说明"的闸门。
|
|
@@ -21,7 +21,7 @@
|
|
|
21
21
|
|
|
22
22
|
<rect width="1440" height="840" fill="#ffffff"/>
|
|
23
23
|
|
|
24
|
-
<text x="40" y="48" class="title">把 Agent
|
|
24
|
+
<text x="40" y="48" class="title">把 Agent 接进钉钉:运行平台可替换,判断与门禁不变</text>
|
|
25
25
|
<text x="40" y="75" class="subtitle">本仓库是连接层:不发身份、不建 Runtime、不复制 DWS 命令面——只把 Agent 装配成合格的钉钉数字员工。</text>
|
|
26
26
|
|
|
27
27
|
<!-- ── 泳道 1:运行位置 ───────────────────────────────── -->
|
|
@@ -21,7 +21,7 @@
|
|
|
21
21
|
</defs>
|
|
22
22
|
<rect width="1200" height="880" fill="#ffffff"/>
|
|
23
23
|
<text x="40" y="46" class="title">dingtalk-agent 架构:五个部件,五个权威,本仓库只拥有一个</text>
|
|
24
|
-
<text x="40" y="70" class="subtitle"
|
|
24
|
+
<text x="40" y="70" class="subtitle">在你熟悉的终端里,把现成的 Agent 装配成合格的钉钉数字员工。实心编号 = 本仓库拥有;空心编号 = 外部提供。</text>
|
|
25
25
|
<rect x="40" y="92" width="1120" height="122" rx="8" fill="#f9fafb" stroke="#d1d5db" stroke-width="1.5" stroke-dasharray="7 5"/>
|
|
26
26
|
<circle cx="62" cy="110" r="11" fill="#ffffff" stroke="#64748b" stroke-width="1.6"/>
|
|
27
27
|
<text x="62" y="114" text-anchor="middle" fill="#64748b" font-size="12" font-weight="700">5</text>
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@xdxer/dingtalk-agent",
|
|
3
|
-
"version": "0.1.5-beta.
|
|
4
|
-
"description": "
|
|
3
|
+
"version": "0.1.5-beta.14",
|
|
4
|
+
"description": "在你熟悉的终端里,用手边的 Coding Agent 把现成的 Agent 装配成钉钉数字员工:建起来、部署交付、评测、观察四段全程有引导,硬门禁只挡不可逆的副作用。",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"dingtalk",
|
|
7
7
|
"agent",
|